On Tuesday, 30 September 2014 at 17:51:18 UTC, Steven
Schveighoffer wrote:
On 9/30/14 1:23 PM, Sean Kelly wrote:
(except for the
definition of the APPENDABLE BlkAttr, which really should be
defined externally and within the user-reserved range of the
bitfield instead of the GC-reserved range, but I digress...)
The APPENDABLE bit was added as a solution to avoid having to
reserve that memory for all allocations. Basically, if you try
to append to a block that doesn't have the bit, it simply
reallocates conservatively.
So it does have to be part of the GC metadata, because the most
important effect is on blocks that AREN'T allocated via the
array runtime. Otherwise, the append mechanism creeps into all
aspects of memory allocation.
Yeah I know. But when I defined the BlkAttr bitfield I'd
reserved one portion of the range for internal GC stuff and
another portion for user-defined stuff. APPENDABLE should
probably have landed in the user-defined portion. I don't see
any of those comments in the current code or I'd point to them.
I guess they were deleted at some point.
