On 2014-11-17 9:45 AM, Kagamin wrote:
Previous thread: http://forum.dlang.org/post/[email protected]
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)
