std.allocator ready for some abuse

[Martin Nowak]

On 10/24/2013 09:54 PM, Andrei Alexandrescu wrote:
> Hello,
>
>
> I know it's been a long wait. Hopefully it was worth it. The alpha
> release of untyped allocators is ready for tire-kicking and a test drive.
>
> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>
> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html

This looks really promising.
There are a lot of building blocks and the way different capabilities 
are modelled by optional methods nicely solves the biggest difficulty 
with allocators.
I think it's important to put this in it's own github repo and add a dub 
package for it on code.dlang.org so that it's easy to test the 
implementation and to contribute improvements.

That said it failed my litmus test.
I previously used David Simcha's RegionAllocator
https://github.com/dsimcha/TempAlloc/blob/master/std/allocators/region.d.

The pattern is to allocate some metadata followed by allocating many 
fixed size tree nodes. When the tree is constructed it is used to render 
an image which is the result of that operation.
The tree and all metadata is freed and the region allocator is reused 
for the next method invocation (it keeps the memory).

I think the closest would be to use CascadingAllocator with Region but 
there are two issues.

CascadingAllocator successively tries all allocators and if that fails 
creates a new region. So this runs in O(N) complexity even though most 
of the time only the last allocator will have memory available.

There is no simple way to deallocateAll without freeing the regions.
What I need is something similar to clear in appender.
I also can't relinquish the memory from the inner regions because they 
are private.

So for my use-case the only way that I found to use this module
is to compute the upper bound of memory needed when the renderer is 
invoked. Then I have to relinquish the buffer from a region, reallocate 
it using Mallocator.it and construct a new region with the reallocated 
buffer.

This works only because I can cheaply compute the upper bound of 
required memory. This wouldn't work in other scenarios.
I think this a very important use-case, e.g. using an auto-growing 
thread local region is what I would use to serve HTTP requests.
But for this one might also want to use nested regions.