A different, precise TLS garbage collector?

Etienne Cimon via Digitalmars-d digitalmars-d at puremagic.com
Sun Nov 16 16:44:15 PST 2014


On 2014-11-16 19:32, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> 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?

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.

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?


More information about the Digitalmars-d mailing list