Shared keyword and the GC?

[deadalnix]

Le 19/10/2012 08:49, Alex Rønne Petersen a écrit :
> On 17-10-2012 16:26, deadalnix wrote:
>> Why not definitively adopt the following (and already proposed) memory
>> scheme (some practice are now considered valid when this scheme is not
>> respected) :
>>
>> Thread local head (one by thread) -> shared heap -> immutable heap
>>
>> This model have multiple benefices :
>> - TL heap only can be processed by only interacting with one thread.
>> - immutable head can be collected 100% concurently if we allow some
>> floating garbage.
>> - shared heap is the only problem, but as its size stay small, the
>> problem stay small.
>
> Can you elaborate? I'm not sure I understand.
>

OK let me detail a little more.

First, I'll explain TL GC. You have to understand shared heap here as 
both shared and immutable heap.

TL collection can be done disturbing only one thread. When the TL 
collection is done, a set of pointer to shared heap is known.

Now, all new pointer in the TL heap to shared heap is either :
  - a new allocation.
  - a pointer read from the shared heap.

So, basically, at the end, we have a set of root to collect the shared 
heap. The thread can continue to run when the shared heap is collected.

Now let's consider the immutable heap. Given a set of root from TL and 
shared, the immutable heap can be collected concurrently. I think it is 
straightforward and will not elaborate.

So the problem is now the shared heap. Here is how I see its collection. 
When the GC want to collect shared it first signal itself to each thread 
that will GC TL data and give back a set of root. As of this point, the 
GC mark all new allocation as live and set a write barrier on shared : 
when a shared object is written, it is marked ive (obviously), its old 
value is scanned, and its new value is scanned too. The reason is pretty 
simple : the old value may have been read by a thread and stored 
locally. When the collection is done, the write barrier can be removed. 
Obviously, the write barrier is not needed for immutable object or any 
shared write that isn't a pointer write, which lead to a very nice way 
to collect things.

The obvious drawback is that pointer for TL to another TL or from shared 
to TL will confuse the GC. But it is already not @safe anyway.