On 9/30/14 2:19 PM, Sean Kelly wrote:
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.
Hm... looked at the code, I have no idea how the GC would handle
user-defined stuff. It seems to only deal with bits it knows about (i.e.
APPENDABLE is specifically handled in gc/gc.d)
I think I just took the next bit available, if there was a warning about
GC internal bits when I added APPENDABLE, I either missed it or
dismissed it.
-Steve
