[Issue 10589] GC.malloc(sz, GC.BlkAttr.APPENDABLE) fails after a certain size

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Jul 14 09:41:04 PDT 2013


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


monarchdodra at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #6 from monarchdodra at gmail.com 2013-07-14 09:41:03 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > Ok. I have just some tiny questions left, if you'd care to instruct me:
> > 1. Why does the "Place at beginning" scheme start at 2K bytes, when a page is
> > 4K byte?
> 
> It is necessary to support alignment attributes in arrays of structs (at least
> up to 16) or alignment for SIMD vectors.

That makes sense I guess. By keeping it to a default 16, it avoids the overhead
and complexity of calculating alignement.

> > 2. Why is the padding 16 bytes? You'd think 8 is enough...? Is there a reason,
> > or is it just "future proofing"?
> 
> Allocation sizes below 4k are rounded up to the next power of 2, so if the
> allocation is larger than 2048, a full page is used by the GC. The array
> functions then assume that extending is possible and place information at the
> start of the buffer.

Derp.

> All this is very specific to the currnt GC implementation.

This. Because it is so specific, I have the feeling that all that has been said
here is useless at the end of the day. Only writters of druntime, or users who
are writting their own GC, could make use of this. The end user, even a library
writer, can't make use of this information.

> > I'll write up the info acquired and update the doc.
> 
> Thanks.

I think I'll just end up writing that the only thing it does (technically) is
set the bit "APPENDABLE" to the memory block. That its exploitation is
ultimately implementation dependent.

--------

I was able to work around my issue though: By using reserve + assumeSafeAppend,
I can get what it was that I wanted to work:

Check this out:
ushort[] a;
a.reserve(20); //GC appendable allocation.
a = a.ptr[0 .. 20]; //occupy space
assumeSafeAppend(a); //Take ownership of used space
assert(a.capcity >= 20);

Pretty neat huh?

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