--- Comment #8 from David Simcha <dsim...@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
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: -------