An important pull request: accessing shared affix for immutable data

[deadalnix via Digitalmars-d]

On Friday, 12 February 2016 at 19:12:48 UTC, Andrei Alexandrescu 
wrote:
> https://github.com/D-Programming-Language/phobos/pull/3991
>
> A short while ago Dicebot discussed the notion of using the 
> allocator to store the reference count of objects (and 
> generally metadata). The allocator seems to be a good place 
> because in a way it's a source of "ground truth" - no matter 
> how data is qualified, it originated as untyped mutable bytes 
> from the allocator.
>
> So after thinking a bit I managed to convince myself that the 
> affixes in an AffixAllocator can be accessed with removing 
> immutable, but without actually breaking any guarantee made by 
> the type system. (Affixes are extra bytes allocated before and 
> after the actual allocation.) The logic goes as follows:
>
> * If the buffer is mutable, then the allocator assumes it 
> hasn't been shared across threads, so it returns a reference to 
> a mutable affix.
>
> * If the buffer is const, then the allocator must 
> conservatively assume it might have been immutable and 
> subsequently shared among threads. Therefore, several threads 
> may request the affix of the same buffer simultaneously. So it 
> returns a reference to a shared affix.
>
> * If the buffer is shared, then the allocator assumes again 
> several threads may access the affix so it returns a reference 
> to a shared affix.
>
> One simple way to look at this is: the allocator keeps an 
> associative array mapping allocated buffers to metadata (e.g. 
> reference counts). The allocated buffers may be immutable, 
> which doesn't require the metadata to be immutable as well. The 
> only difference between an approach based on an associative 
> array and AffixAllocator is that the latter is faster (the 
> association is fixed by layout).
>
>
> Destroy!
>
> Andrei

So if I may, I think we should avoid affix data in the general 
case.

Providing some metadata in the allocate is in itself a good idea. 
Locating these data with the object is usually not :
  - Mutating the metadata will create sharing overhead on the 
whole cache line. Sharing of immutable would become inefficient.
  - It tends to create allocation size that aren't friendly to 
underlying allocators. For instance, an alocation of size 2^n + 8 
bumps you to the next size class, often 2^(n+1) or alike. This 
creates a lot of internal fragmentation.
  - Buffer overflow/underflow WILL spill in the alocator metadata. 
You don't want that. This pretty much guaranteed that the worse 
thing that can happen will happen: corrupting the alocator.

jemalloc moved away from using them for small runs for these 
reasons.