An important pull request: accessing shared affix for immutable data

[ZombineDev via Digitalmars-d]

On Saturday, 13 February 2016 at 22:01:45 UTC, deadalnix wrote:
> On Saturday, 13 February 2016 at 21:10:50 UTC, Andrei 
> Alexandrescu wrote:
>> There's no need. I'll do the implementation with the prefix, 
>> and if you do it with a global hashtable within the same or 
>> better speed, my hat is off to you.
>>
>
> That is false dichotomy. What about storing the metadata at an 
> address that is computable from from the object's address, 
> while not being contiguous with the object allocated ? Is 
> substracting a constant really the only option here ? (hint, it 
> is not)

1) False-sharing overhead:
If you look at the case where the allocated data is non-shared, 
you'll get better cache locality, instead of sharing overhead on 
the cache coherency system.

2) Unfriendly allocation size:
In general you're correct, but in the end, it depends on the type 
of data. If you consider the case of shared_ptr - refcount as 
metadata + ptr as the actual allocation - you get a nice 
allocation size of 2*size_t.sizeof.
As I see it, AffixAllocator is not a silver bullet, but in some 
very specific cases it can actaully be a very good fit. You just 
have to carefully consider this case-by-case. E.g. for shared 
types with irregular size we can just switch to a different 
allocator - that's the whole point of the composable allocators.

3) Increased probability/danger of buffer overflow/underflow:
First, I would say that things like slice bounds checks make D a 
safer language for the average user than C/C++, which should make 
this a bit less of a problem.
Second, I actually think that even if this suddenly leads to a 
lot of problems for the end users, this would bring more pressure 
for adding more Ada/Rust-like static analysis for D - which is a 
Good Thing.