A different, precise TLS garbage collector?

[via Digitalmars-d]

On Monday, 17 November 2014 at 00:44:13 UTC, Etienne Cimon wrote:
> I'm not sure what this means, wouldn't the fiber stacks be 
> saved on the thread-local space when they yield? In turn, they 
> become part of the thread-local stack space I guess.

If you want performant, low latency fibers you want load 
balancing, so they should not be affiliated with a thread but 
live in a pool.

That said, fibers aren't a low level construct like threads so I 
am not sure if they belong in system level programming anyway.

> Overall, I'd put all the GC allocations through malloc the same 
> way it is right now. I don't see anything that needs to be done 
> other than make multiple thread-local GC instances and remove 
> the locks. I'm sure I'll find obstacles but I don't see them 
> right now, do you know of any that I should look out for?

Not if you work hard to ensure referential integrity. I 
personally would find it more useful with an optional GC where 
the programmer takes responsibility for collecting when the 
situation is right. (specifying root pointers, stack etc).

I think the language should limit itself to generate the 
information that can enable precise collection, then leave the 
rest to the programmer…