On Thursday, 13 November 2014 at 10:10:34 UTC, Marc Schütz wrote:
On Wednesday, 12 November 2014 at 21:15:05 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 12:49:41 UTC, Marc Schütz
wrote:
All this is unfortunately only true if there are no
references between heaps, i.e. if the heaps are indeed
"islands". Otherwise, there need to be at least write
barriers.
Yes, that is exactly why I'm listing the case where these can
be created in @safe code and propose a solution to plug the
hole (and which brings other benefits along the road).
Hmm... I can't find that in what you wrote. To clarify: I'm
talking about the fact that, for example, a thread-local heap
can contain references into the immutable and shared heaps.
Therefore, the immutable heap can _not_ be collected without
disturbing any threads, because any TL heaps (and stacks!) can
potentially have references to it. They either need to be
stopped, or write barriers need to be utilized when references
to immutable data are changed.
You need a set of root from the TL heap. The trick being to
consider everything that is allocated AFTER you get the roots as
automatically alive (you'll collect this in the next collection
cycle).
That way, new allocated chunk that have reference in the TL heap
will be kept alive, even if you don't know about the roots.
You'll find plenty of information about the details if look into
GC for ML family languages.
