A different, precise TLS garbage collector?
Etienne via Digitalmars-d
digitalmars-d at puremagic.com
Sun Nov 16 05:58:17 PST 2014
I always wondered why we would use the shared keyword on GC allocations
if only the stack can be optimized for TLS Storage.
After thinking about how shared objects should work with the GC, it's
become obvious that the GC should be optimized for local data. Anything
shared would have to be manually managed, because the biggest slowdown
of all is stopping the world to facilitate concurrency.
With a precise GC on the way, it's become easy to filter out allocations
from shared objects. Simply proxy them through malloc and get right of
the locks. Make the GC thread-local, and you can expect it to scale with
the number of processors.
Any thread-local data should already have to be duplicated into a shared
object to be used from another thread, and the lifetime is easy to
manage manually.
SomeTLS variable = new SomeTLS("Data");
shared SomeTLS variable2 = cast(shared) variable.dupShared();
Tid tid = spawn(&doSomething, variable2);
variable = receive!variable2(tid).dupLocal();
delete variable2;
Programming with a syntax that makes use of shared objects, and forces
manual management on those, seems to make "stop the world" a thing of
the past. Any thoughts?
More information about the Digitalmars-d
mailing list