digitalmars.D.learn - Precise & TLS GC
Etienne <etcimon gmail.com> writes:
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?
Nov 16 2014