[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 #8 from David Simcha <dsimcha at yahoo.com> 2009-11-03 08:06:43 PST ---
(In reply to comment #7)
> Nice work!  It may be preferable to store the pointer elsewhere however.  I
> believe all blocks returned by the allocator must be 16 byte-aligned, so
> tacking a pointer onto the end of a block either screws this up or uses up a
> lot more space than necessary.  

I don't understand.  If someone requests, for example, a 12-byte allocation,
the pointer is stored in the last 4 bytes (on 32-bit) of a 16-byte block.  I
don't increase the block capacity unless I have to.  Yes, occasionally it will
result in a doubling of the required capacity, but unless you request an
allocation within 4 bytes of a full block size, it uses no extra space.  The
expected value under pseudo-random allocation sizes is probably (I haven't
worked this out formally) only 4 bytes on 32-bit.

Furthermore, if the NO_SCAN bit is set, no bit mask information at all is
stored.  This optimization was part of the reason I chose to use the end of the
block:  Otherwise I probably would have had to reserve space somewhere else
before I knew the status of the NO_SCAN bit, meaning that this optimization
would have been unimplementable.

> I also kind of wish that the pointer didn't
> have to be stored at all for small block sizes, since simply storing the mask
> itself would take up less space (admittedly, at the expense of more complicated
> logic).

I thought about this, but the problem I kept coming up with was that tracking
the size of the mask would require a couple bytes anyhow.  IMHO it was
important to keep this patch relatively simple and stupid and easy to debug. 
It's clearly not a long-term solution to our GC woes because it leaves
unaddressed so many unrelated issues that will eventually require a full
redesign.  It's more of an incremental improvement to make the GC "good enough"
until D is popular enough that some GC expert implements generational, moving,
parallel, etc. GC.

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