The problem with the D GC

[Frits van Bommel]

Sean Kelly wrote:
> Frits van Bommel wrote:
>> Also: Why two locks per concat at all? A concat only requires one 
>> allocation, so does a single alloc require two locks?
>> (I haven't looked much into the GC code, so this is just curiosity)
> 
> The code in internal/gc/gc.d first checks the size of the array to see 
> if a realloc is necessary, then it performs the realloc.  So worst case 
> you're stuck with two locks per operation.  However, this may not be the 
> case in the arraycat routines.  It's been a while since I've looked at 
> them.

Normal concats always allocate, so there's no need to check the size 
(and so they don't).
You're probably thinking of appends.

>> If you don't want to use them at all, I think the closest you'd get 
>> would involve implementing thread-local heaps.
>> But that would still require a mutex if you want to allow deleting an 
>> object from a different thread than it was allocated in...
> 
> No it wouldn't--give each per-thread heap a lock-free free list.  But 
> per-thread heaps for a GC are somewhat complicated.  I think you'd have 
> to implement something like a read/write lock where the "writer" is 
> actually the thread that wants to collect.

I replied to myself about 10 minutes later when I realized it was 
probably possible :).