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