GC.sizeOf(array.ptr)

[Steven Schveighoffer via Digitalmars-d]

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