The "no gc" crowd

[Sean Kelly]

On Oct 9, 2013, at 8:23 AM, deadalnix <deadalnix at gmail.com> wrote:

> On Wednesday, 9 October 2013 at 14:17:44 UTC, Sean Kelly wrote:
>> On Oct 9, 2013, at 4:30 AM, Jacob Carlborg <doob at me.com> 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.