On Wednesday, 1 October 2014 at 09:52:46 UTC, Andrei Alexandrescu
wrote:
On 9/30/14, 12:10 PM, "Marc Schütz" <schue...@gmx.net>" wrote:
I would argue that GC is at its core _only_ a memory management
strategy. It just so happens that the one in D's runtime also
comes with
an allocator, with which it is tightly integrated. In theory,
a GC can
work with any (and multiple) allocators, and you could of
course also
call GC.free() manually, because, as you say, management and
allocation
are entirely distinct topics.
I'm not very sure. A GC might need to interoperate closely with
the allocator. -- Andrei
It needs to know what to scan (ideally with type info), and which
allocator to release memory with, but it doesn't need to be an
allocator itself. It certainly helps with the implementation, but
ideally there would be a well defined interface between
allocators and GCs, so that both can be plugged in as desired,
even with multiple GCs in parallel.
