Allocators stack

[via Digitalmars-d]

On Monday, 22 December 2014 at 16:51:30 UTC, Allocator stack 
wrote:
> How about allocators stack? Allocator e.g. one of these
> https://github.com/andralex/phobos/blob/allocator/std/allocator.d
> -------------
> allocatorStack.push(new GCAllocator);
> //Some code that use memory allocation
> auto a = ['x', 'y'];
> a ~= ['a', 'b']; // use allocatorStack.top.realloc(...);
> allocatorStack.pop();
> -------------
> Allocators must be equipped with dynamic polymorphism. For those
> cases when it is too expensive attribute
> @allocator(yourAllocator) applied to declaration set allocator
> statically.
>
> -------------
> @allocator(Mallocator.instance)
> void f()
> {
> // Implicitly use global(tls?) allocator Mallocator when 
> allocate an
> object or resize an array or etc.
> }
>
> @allocator("StackAllocator")
> void f()
> {
> // Implicitly use allocatorStack.top() allocator when allocate 
> an
> object or resize an array or etc.
> }
> -------------
>
> There is some issues to solve. E.g. how to eliminate mix memory 
> from different allocators.

I've put together some semi-realistic code that touches on this 
(ignore the `scope` thingies in there):
http://wiki.dlang.org/User:Schuetzm/RC,_Owned_and_allocators

The goal was to allow returning owned objects from functions that 
don't know what kind of memory management strategy the end user 
wants to use. The caller can then decide to convert them into ref 
counted objects, or release them and let the GC take care of 
them, or just use them in a UFCS chain and let them get destroyed 
at the end of the current statement automatically.

This is achieved by storing a pointer to the allocator (which is 
an interface) next to the object. (As a side note, these 
interfaces can be auto-implemented by templates when needed, 
similar to `std.range.InputRange` et al.)

This design makes it possible to switch allocators at runtime in 
any order, either through a global variable, or by passing a 
parameter to a function. It also avoids template bloat, because 
the functions involved just need to return Owned!MyType, which 
does not depend on the allocator type. The downside is, of 
course, the overhead of the indirect calls. (The call to 
`reallocate` can be left out in this example if `Owned` already 
preallocates some space for the refcount, therefore it's just two 
indirect calls for the lifetime of a typical object: one each for 
creation and destruction.)

As for static allocators, I think it's not possible without 
sacrificing the ability to switch allocators at runtime and 
without templating on the allocator.