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.
