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