On Sunday, 16 November 2014 at 13:58:19 UTC, Etienne wrote:
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?
How about immutable data which is implicitly shareable? Granted
you can destroy/free the data asynchronously, but you would still
need to check all threads for references to that data.
