why allocators are not discussed here

[H. S. Teoh]

On Wed, Jun 26, 2013 at 12:22:04AM +0200, cybervadim wrote:
> I know Andrey mentioned he was going to work on Allocators a year
> ago. In DConf 2013 he described the problems he needs to solve with
> Allocators. But I wonder if I am missing the discussion around that
> - I tried searching this forum, found a few threads that was not
> actually a brain storm for Allocators design.
> 
> Please point me in the right direction
> or
> is there a reason it is not discussed
> or
> should we open the discussion?

That would be nice to get things going. :)

Ever since I found D and subscribed to this mailing list, I've been
hearing rumors of allocators, but they seem to be rather lacking in the
department of concrete evidence. They're like the Big Foot or Swamp Ape
of D. Maybe it's time we got out into the field and produced some real
evidence of these mythical beasts. :-P


> The easiest approach for Allocators design I can imagine would be to
> let user specify which Allocator operator new should get the memory
> from (introducing a new keyword allocator). This gives a total
> control, but assumes user knows what he is doing.
> 
> Example:
> 
> CustomAllocator ca;
> allocator(ca) {
>   auto a = new A; // operator new will use ScopeAllocator::malloc()
>   auto b = new B;
> 
>   free(a); // that should call ScopeAllocator::free()
>   // if free() is missing for allocated area, it is a user
> responsibility to make sure custom Allocator can handle that
> }
> 
> By default allocator is the druntime using GC, free(a) does nothing
> for it.

I believe the current direction is to avoid needing new language
features / syntax. So the above probably won't happen.


> if some library defines its allocator (e.g. specialized container),
> there should be ability to:
> 1. override allocator
> 2. get access to the allocator used
> 
> I understand that I spent 5 mins thinking about the way Allocators
> may look.
> My point is - if somebody is working on it, can you please share
> your ideas?

Well, thanks for getting the ball rolling. Maybe Andrei can pipe up
about any experimental designs he's currently considering.

But barring that, I'm thinking about how allocators would be used in
user code. I think it's pretty much a given that the C++ way of sticking
it to the end of template arguments doesn't really fly: it's just too
much of a hassle to keep having to worry about passing allocators around
template arguments, that people just don't bother. So coming back to
square one, how would allocators be used?

1) Usually, the user would just be content with the GC, and not ever
have to worry about allocators. So this means that whatever allocator
design we adopt, it should be practically invisible to ordinary users
unless they're specifically looking to change how memory is allocated.

2) Furthermore, it's unlikely that in the same piece of code, you'd want
to use 3 or 4 different allocators for different objects; while such
cases may exist, it seems to me to be more likely that you want either
(a) a very specific object (say a class instance or container) to use a
particular allocator, or (b) you want to transitively block off an
entire section of code (which may be the entire program in some cases)
to use a particular allocator.

As a first stab at it, I'd say (a) can be implemented by a static class
member reference to an allocator, that can be set from user code.

And maybe (b) can be implemented by making gc_alloc / gc_free
overridable function pointers? Then we can override their values and use
scope guards to revert them back to the values they were before. This
allows us to use the runtime stack to manage which allocator is
currently active. This lets *all* memory allocations be rerouted through
the custom allocator without needing to hand-edit every call to new down
the call graph.

This is just a very crude first stab at the problem, though. In
particular, (a) isn't very satisfactory. And also the interaction of
allocated objects with the call stack: if any custom-allocated objects
in (b) survive past the containing function which sets/resets the
function pointers, there could be problems: if a member function of such
an object needs to allocate memory, it will pick up the ambient
allocator instead of the custom allocator in effect when the object was
first created. Also, we may have the problem of the wrong allocator
being used to free the object.

Anyone has better ideas?


T

-- 
All problems are easy in retrospect.