why allocators are not discussed here

cybervadim vadim.goryunov at gmail.com
Tue Jun 25 16:11:41 PDT 2013


On Tuesday, 25 June 2013 at 22:50:55 UTC, H. S. Teoh wrote:
> On Wed, Jun 26, 2013 at 12:22:04AM +0200, cybervadim wrote:
>
> 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
>
> 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

 From my experience all objects may be divided into 2 categories
1. temporaries. Program usually have some kind of event loop. 
During one iteration of this loop some temporary objects are 
created and then discarded. The ideal case for stack (or ranged 
or area) allocator, where you define allocator at the beginning 
of the loop cycle, use it for all temporaries, then free all the 
memory in one go at the end of iteration.
2. containers. Program receives an event from the outside and 
puts some data into container OR update the data if the record 
already exists.
The important thing here is - when updating the data in 
container, you may want to resize the existing area.

If you are working with temporary which should be placed into 
container, a copy can be made (with corresponding memory 
allocation from container allocator).

Not sure if there is anything better than stack/area allocator 
for the first class. For the second class user should be able to 
choose default GC or more precise memory handling (e.g. explicit 
malloc/free for resizing).

Anything I am missing in this categorization?

So even if we get allocators that lets us deal with temporaries, 
that will be a huge benefit.


More information about the Digitalmars-d mailing list