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

[d-bugmail at puremagic.com]

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


monarchdodra at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|druntime                    |websites
           Severity|major                       |enhancement


--- Comment #4 from monarchdodra at gmail.com 2013-07-14 03:18:00 PDT ---
(In reply to comment #3)
> >Is the memory layout for the APPENDABLE data documented somewhere, or are these
> just reverse-engineered magic numbers?
> 
> There is some description in rt/lifetime.d starting around line 200.
> 
> >Nope (I think). Length is carried in the slice, not the block. 
> > Block only contains capacity/used info.
> 
> Sorry, I meant the "used" info that must be reset.
> 
> >In particular, the magic numbers should be user accessible via manifest
> > constants, or functions, so as to not have to guess/reverse engineer them. 
> 
> The constants are defined privately in lifetime.d as SMALLPAD, MEDPAD and
> LARGEPAD. I suspect the trailing byte for large arrays is added so that
> arr[$..$] always points into the same memory block, and not the next one.

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?
2. Why is the padding 16 bytes? You'd think 8 is enough...? Is there a reason,
or is it just "future proofing"?

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

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