[Issue 4400] D2 GC doesn't allocate with 16 bytes alignment

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Jun 28 10:59:13 PDT 2010


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



--- Comment #3 from Steven Schveighoffer <schveiguy at yahoo.com> 2010-06-28 10:59:08 PDT ---
It was changed when I added the append patch.

By default the GC was 16-byte aligned, because all allocations below a page
were in some power of 2 increments, starting with 16 bytes.

The append patch needs to store the "used length" of the block somewhere in the
block itself.  What I discovered is that the array runtime functions stored a
padding byte at the end of every array.  This was to prevent pointers that
point to the end of the array from being considered as part of the next block
of memory.

So I used that byte to store the length.  I used it for blocks up to and
including 256 bytes (255 usable bytes).  For blocks 512 to 2048 bytes, I use 2
bytes to store the length.

For blocks page size and above, I use a full size_t.  However, it is possible
to append to an array and have it just commandeer empty pages after the used
pages, thereby changing the allocated block length.  This means that if I
stored the length at the end of the block, the length would have to be moved
when adding more pages, and the caching scheme could get messed up.  So I
decided to store the length at the front of the block.  In order to satisfy
alignment requirements, I had to add some padding to get the alignment to work.
 I asked around and was told that 8-byte alignment is sufficient.  If that is
wrong or makes sense to change, it is an easy fix.

I will bring up your concerns on the phobos mailing list and see what people
say.

-- 
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