On Oct 9, 2013, at 8:23 AM, deadalnix <[email protected]> wrote: > On Wednesday, 9 October 2013 at 14:17:44 UTC, Sean Kelly wrote: >> On Oct 9, 2013, at 4:30 AM, Jacob Carlborg <[email protected]> wrote: >>>> On 2013-10-09 05:31, Walter Bright wrote: >>>> Making this work is fraught with difficulty. It is normal behavior in D >>>> to create local data with new(), build a data structure, and then cast >>>> it to shared so it can be transferred to another thread. This will fail >>>> miserably if the data is allocated on a thread local heap. >>> I agree with Andrei here. Alternatively perhaps the runtime can move the >>> data to a global pool if it's casted to shared. >> >> Generally not, since even D's precise GC is partially conservative. It's >> also way more expensive than any cast should be. For better or worse, I >> think being able to cast data to shared means that we can't have >> thread-local pools. Unless a new attribute were introduced like "local" that >> couldn't ever be cast to shared, and that sounds like a disaster. > > That isn't accurant. Allocator like tcmalloc use thread local info to > allocate shared chunk of memory. What does matter is that the block is tagged > as shared as far as the GC is concerned.
If the GC can determine whether a block is shared at allocation time, it can allocate the block from a thread-local pool in the unshared case. So if a collection is necessary, no global stop the world need occur. Only the current thread's roots are scanned. It's a huge performance gain in a concurrent program. Particularly in a language like D where data is thread-local by default.
