A different, precise TLS garbage collector?

[Etienne via Digitalmars-d]

On 2014-11-17 9:45 AM, Kagamin wrote:
> Previous thread:
> http://forum.dlang.org/post/dnxgbumzenupviqymhrg@forum.dlang.org

Looks somewhat similar but the idea of a shared GC will defeat the 
purpose and will end up complicating things. After another review of the 
problem, I've come up with some new observations:

- The shared data needs to be manually managed for a thread-local GC in 
order to scale with the number of CPU cores

- Anything instantiated as `new shared X` will have to proxy into a 
shared allocator interface or malloc.

- All __gshared instances containing mutable indirections will cause 
undefined behavior

- All thread-local instances moved through threads using cast(shared) 
and carrying indirections will cause undefined behavior

- Immutable object values must not be allocated on the GC and defined 
only in a shared static this constructor to ensure the values are 
available to all threads at all times

The only necessity is shared/non-shared type information during 
allocation and deallocation.

The __gshared and cast(shared) issues are certainly the most daunting. 
This is why this GC would have to be optional through a 
version(ThreadLocalGC)