A few thoughts on std.allocator

[Timon Gehr via Digitalmars-d]

On 05/10/2015 11:50 AM, Andrei Alexandrescu wrote:
> In C, C++, and D people have allocated memory for a long time in the
> following manner:
> ...
> Long story short, arrays should sit on a different heap than objects.
> ...

Unless this has been fixed in the interim, I believe DMD lowers new 
S(args) to [S(args)].ptr for struct S. It should be ensured that the 
global allocator will not be misinformed about the kind of allocation 
that takes place, by removing this lowering.


> 3. Thread-local vs. shared objects
>
> Currently in D it's legal to allocate memory in one thread and
> deallocate it in another. (One simple way to look at it is casting to
> shared.) This has a large performance cost that only benefits very few
> actual cases.
>
> It follows that we need to change the notion that you first allocate
> memory and then brand it as shared. The "will be shared" knowledge must
> be present during allocation, and use different methods of allocation
> for the two cases.
>
> ...
> 6. Immutable vs. mutable
>
> I'm not sure how this can be practically exploited. There must be
> something in the notion that, save for a brief write period after
> allocation, the memory will stay unmodified. Still thinking.
> ...

Keep in mind that currently, entire regions of memory can change from 
mutable to immutable implicitly when returned from pure functions. 
Furthermore, as Michel points out, the ways 'immutable' can be leveraged 
is constrained by the fact that it implies 'shared'.