On heap segregation, GC optimization and @nogc relaxing

[deadalnix via Digitalmars-d]

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.