[D-runtime] Metadata for memory

[Fawzi Mohamed]

On 30-lug-10, at 16:44, Steve Schveighoffer wrote:

> ----- Original Message ----
>> From: Fawzi Mohamed <fawzi at gmx.ch>
>>
>> Actually I  don't see the need of more info about a block than  
>> size, and
>> character  (equivalent to the typeid of what was allocated).
>> Anything else of interest  can be derived from that.
>
> The "used" length of an array is not a static value.  It needs to be  
> stored
> separate from the typeinfo.  The block size is identified by the  
> pool or by
> doing a linear search on large blocks (this also needs to be  
> addressed at some
> point).
>
>> Given this one could think about hardcoding  that in some way in  
>> the block.
>> The rest should be stored elsewhere imho (one  can expect that the  
>> table to
>> reach other info will be cached when used, as it  should be  
>> relatively small).
>>
>> Still I would give more thought about  storing also those two  
>> pieces of
>> information outside the block.
>> The pool  already knows the size, and one could add a (uint/ 
>> size_t?) per
>> element to store  the  character.
>
> Note that as I said above, the "used size" must be stored somewhere  
> besides the
> "character", and also note that for arrays, a pad byte is inherent  
> in the memory
> block to avoid pointers moving to the next block (which might  
> possibly be
> unallocated).  So we already are using a byte inside the block for  
> something,
> might as well make some use of it.
>
> For non-arrays, I'm unsure.  An external pointer might be fine, but  
> for small
> blocks, it can be up to 25% overhead if you are storing a size_t.

Yes I realized as much after having sent it, thus my previous repost.
Exactly in those cases as separate bitmap for the whole pool is much  
advantageous, and also the size could be done the same way, one would  
use special encoding for the pools of small objects (one could use  
even less than one byte for B_16, B_32,...)
Being "external" no clashes are possible...

Fawzi