[Issue 3463] Integrate Precise Heap Scanning Into the GC

[d-bugmail at puremagic.com]

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



--- Comment #44 from Leandro Lucarella <llucax at gmail.com> 2010-07-23 12:15:44 PDT ---
(In reply to comment #43)
> You're right, there seem to be some places where the bitmask size is added or
> substracted twice. I don't really know; I took that code over from dsimcha's
> patch without modification. I was just thankful that I hadn't to write this
> code. I fixed the three issues you found. It seems to work, though I'm not 100%
> sure if it's correct now.

Thanks!

> Regarding moving collectors:
> 
> I think this would be an interesting experiment and worth trying. My patch now
> has a second bitmask, where each bit tells whether a word is a moveable
> pointer or not.
> 
> Instead of a second bitmap, you could just have a per-memory block flag that
> tells whether a memory block is a void[] and/or contains unions with pointers.
> (If the flag is set, the GC won't change any pointers inside the block.) You
> could maintain that flag as additional bitmap (along NOSCAN etc). This way
> storing small bitmaps inline would be simpler. Unions or fixed-size void[] are
> probably seldom enough to justify this simplification. gcx.d can choose either
> way to implement it using the compiler generated bitmasks.

Yes, that can be a nice optimization if void[] and unions are rare.

> Before actually implementing a moving GC, one should experiment how many
> pinned pointers the stack/manually added ranges/unmovable pointers/datasegment
> generate and how they would fragment the heap.

Yup! This patch opens that posibility too! Which is great.

> Also note that some runtime parts are not ready yet for a moving GC, such as
> Object.toHash.

Yes, this is just a step in the right direction, not a final solution.

Thanks again!

A bikeshed suggestion, maybe it would be better to call PointerMap methods this
way:

isPointerAt()           -> mustScanWordAt()
isMoveablePointerAt()   -> isPointerAt() 
hasUnmoveablePointers() -> canUpdatePointers()

Because the pointers are not "moveable", the memory they point at is the one
moveable or not. The pointer, if really pointer, are updateable, and if they
are not guaranteed to be pointers, we shouldn't call them that. That's why I
think is clearer to call a "may be pointer" a word that should be scanned and a
guaranteed pointer (which the GC could update) simply a pointer.

By the same means, I'd call pointer_bits and mpointer_bits scan_bits and
pointer_bits respectively.

BTW, there is already a GC attribute called NO_MOVE, which follows this
nomenclature (is supposed to be used for blocks that can't be moved, not for
blocks which pointers can't be updated).

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