http://d.puremagic.com/issues/show_bug.cgi?id=10589
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Component|druntime |websites Severity|major |enhancement --- Comment #4 from [email protected] 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: -------
