Thread GC non "stop-the-world"

[via Digitalmars-d]

On Tuesday, 23 September 2014 at 18:53:04 UTC, Oscar Martin wrote:
> On Tuesday, 23 September 2014 at 15:28:30 UTC, Marc Schütz 
> wrote:
>> On Tuesday, 23 September 2014 at 15:23:16 UTC, Kagamin wrote:
>>> And what GC does? Pins the allocated blocks for another 
>>> thread?
>>
>> Assuming there is one thread-local GC per thread, it transfers 
>> responsibility of the allocated data from the sender to the 
>> receiver. This means, the old GC doesn't need to scan it any 
>> more, but the new one does.
>
> Yes. A mechanism for transfer of responsibility and pins would 
> be needed.
>
> Basically we have to think that a thread GC just look for roots 
> on his stack/registers and managed memory, and may move the 
> managed objects in a collection, so a reference used in another 
> thread may become invalid for that other thread anytime

Physically moving the objects is not necessary, it only needs to 
"move" the responsibility. With some work, it might even be 
possible to move the objects' metadata from the old to the new 
heap, so that each GC would only need to access its own heap 
during a scan, which avoids synchronization with the other 
threads.