[Issue 3463] Integrate Precise Heap Scanning Into the GC

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Jul 28 12:49:51 PDT 2010


http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #62 from nfxjfg at gmail.com 2010-07-28 12:49:49 PDT ---
(In reply to comment #61)
> Even when I agree that the GC needs a lot of refactoring, I don't think it's a
> good idea to include it in this patch, it makes much harder to understand it
> and it might introduce some subtle bugs that will be very hard to track down in
> so many changes.

I have to agree, but I did these changes in order to make storing a bitmask
configurable, and to properly support SENTINEL. The changes the original patch
did weren't very small either.

I see 4 options:
1. keep this anyway
2. keep the old gcx.d around and apply the changes to a new incarnation of
gcx.d, and let the user choose the GC implementation at startup or compile time
3. only accept the compiler patch, and wait for Leandro's new GC
4. revert to the previous version of my patch (of course I wouldn't like this
at all)

Which is it?

I also wonder about D2. The array appending issue makes porting the Tango patch
non-trivial.

> > Also, shouldn't functions like freeNoSync check for interior pointers? What
> > happens if you call it with such a pointer?
> 
> I don't think so, it should be undefined behavior (based on C's free()).

Then the code should probably check whether the pointer is valid, and abort()
or throw an exception if not. I don't think intentionally introducing random
behavior when you could avoid it is a good idea. Also the documentation
comments in Memory.d seem to disagree with your assessment.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list