A different, precise TLS garbage collector?

[via Digitalmars-d]

On Sunday, 16 November 2014 at 19:13:27 UTC, Etienne wrote:
> I can't even think of a situation when this would be necessary. 
> It sounds like all I would need is to take the precise GC and 
> store each instance in the thread data, I'll probably only need 
> the rtinfo to see if it's shared during allocation to proxy 
> towards malloc. Am I missing something?

There is a reason for why "elegant" GC languages pick one primary 
type of concurrency.

If you say that all code is running on a fiber and that there is 
no such thing as thread local, then you can tie the local GC 
partition to the fiber and collect it on any thread.

If you say that functions called from a fiber sometimes call into 
global statespace, sometimes into thread statespace and sometimes 
into fiber statespace… then you need to figure out ownership on 
all allocations. Does the allocated object belong to a global 
database, a thread local database or a fiber cache which is 
flushed automatically when moving to a new thread? Or is it an 
extension of the fiber statespace that should be transparent to 
threads?