std.allocator needs your help

[BLM768]

On Monday, 23 September 2013 at 17:01:47 UTC, deadalnix wrote:
> What you call safe really isn't. Allocate something on the GC, 
> store a pointer on a custom allocated location, collect, enjoy 
> the memory corruption. All operation are safe according to your 
> proposal. Allocation can only be safe if the GRAND MASTER GC is 
> aware of it.

I don't see why the GC can't be allocator-agnostic. In principle, 
it should be possible to register arbitrary allocators with the 
GC (possibly by storing a pointer to the allocator in each 
GC-managed block of memory). The GC would have a default 
allocator which would be used with the "new" operator, and 
something like the aforementioned create!() syntax could be used 
for custom allocators:

SomeClass c1 = new SomeClass("arg");
//Managed by the GC
SomeClass c2 = gcCreate!SomeClass(someAllocator, "arg");
//Another possible syntax (much prettier!):
SomeClass c3 = someAllocator.new SomeClass("arg");

This could also integrate with DIP46; instead of pushing and 
popping a GC object, one would push and pop the GC's default 
allocator (for the current thread, of course).

There would be a bit of overhead, but that seems to be 
unavoidable in a sufficiently generic design, and I doubt that it 
would cut performance to an unacceptable level, especially 
because really performance-critical code would avoid the GC 
anyway.

> You proposal allocate shared memory. This is common in C/C++ 
> world as memory is shared by default, but shouldn't be in D. It 
> is highly desirable to allocate with different methods for 
> different type qualifier. How does your design adapt to that ?

If the aforementioned thread-local GC reference is implemented, 
it should be possible to provide decent thread-local allocation. 
I'm not sure exactly how to design that, but it seems like 
thread-local GC allocation would require some work at the GC 
level; a global GC won't necessarily play nicely with 
thread-local allocators.

For non-GC thread-local allocations, I'd imagine that you could 
just create a thread-local allocator.