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.
