A different, precise TLS garbage collector?
Xinok via Digitalmars-d
digitalmars-d at puremagic.com
Sun Nov 16 07:21:07 PST 2014
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.
More information about the Digitalmars-d
mailing list