Migrating an existing more modern GC to D's gc.d

[David Bennett]

On Tuesday, 10 April 2018 at 06:47:53 UTC, Jonathan M Davis wrote:
> As it stands, it's impossible to have thread-local memory 
> pools. It's quite legal to construct an object as shared or 
> thread-local and cast it to the other. In fact, it's _highly_ 
> likely that that's how any shared object of any complexity is 
> going to be constructed. Similarly, it's extremely common to 
> allocate an object as mutable and then cast it to immutable 
> (either using assumeUnique or by using a pure function where 
> the compiler does the cast implicitly for you if it can 
> guarantee that the return value is unique), and immutable 
> objects are implicitly shared.
>

(Honest question:) Do people really cast from local to 
shared/immutable and expect it to work?
(when ever I cast something more complex then a size_t I almost 
expect it to blow up... or break sometime in the future)

That said, I can understanding building a shared object from 
parts of local data... though I try to keep my thread barriers as 
thin as possible myself. (meaning I tend to copy stuff to the 
shared and have as few shared's as possible)

>
> At minimum, there would have to be runtime hooks to do 
> something like move an object between pools when it is cast to 
> shared or immutable (or back) in order to ensure that an object 
> was in the right pool, but if that requires copying the object 
> rather than just moving the memory block, then it can't be 
> done, because every pointer or reference pointing to that 
> object would have to be rewritten (which isn't supported by the 
> language).
>

A hook for local to cast(shared) could work... but would require 
a DIP I guess. I was hoping to make a more incremental 
improvement the the GC.

>
> Also, it would be a disaster for shared, because the typical 
> way to use shared is to protect the shared object with a mutex, 
> cast away shared so that it can be operated on as thread-local 
> within that section of code, and then before the mutex is 
> released, all thread-local references then need to be gone. e.g.
>
>
> synchronized(mutex)
> {
>     auto threadLocal = cast(MyType)mySharedObject;
>
>     // do something with threadLocal...
>
>     // threadLocal leaves scope and is gone without being cast 
> back
> }
>
> // all references to the shared object should now be shared
>

Yeah thats why I was still scanning all thread stacks and pages 
when marking global data.
So a shared -> local is a no op but the other way needs thought.

>
> You really _don't_ want the shared object to move between pools
> because of that cast (since it would hurt performance), and in 
> such a
> situation, you don't usually cast back to shared. Rather, you 
> have a shared
> reference, cast it to get a thread-local reference, and then 
> let the
> thread-local reference leave scope. So, the same object 
> temporarily has both
> a thread-local and a shared reference to it, and if it were 
> moved to the
> thread-local pool with the cast, it would never be moved back 
> when the
> thread-local references left scope and the mutex was released.
>
> Having synchronized classes as described in TDPL would make the 
> above code cleaner in the cases where a synchronized class 
> would work, but the basic concept is the same. It would still 
> be doing a cast underneath the hood, and it would still have 
> the same problems. It just wouldn't involve explicit casting. 
> shared's design inherently requires casting away shared, so it 
> just plain isn't going to play well with anything that doesn't 
> play well with such casts - such as having thread-local heaps.
>

I would think a shared class would never be marked as a 
THREAD_LOCAL as it has a shared member.

>
> Also, IIRC, at one point, Daniel Murphy explained to me some 
> problem with classes with regards to the virtual table or the 
> TypeInfo that inherently wouldn't work with trying to move it 
> between threads. Unfortunately, I don't remember the details 
> now, but I do remember that there's _something_ there that 
> wouldn't work with thread-local heaps. And if anyone were to 
> seriously try it, I expect that he could probably come up with 
> the reasons again.
>
> Regardless, I think that it's clear that in order to do 
> anything with thread-local pools, we'd have to lock down the 
> type system even further to disallow casts to or from shared or 
> immutable, and that would really be a big problem given the 
> inherent restrictions on those types and how shared is intended 
> to be used. So, while it's a common idea as to how the GC could 
> be improved, and it would be great if we could do it, I think 
> that it goes right along with all of the other ideas that 
> require stuff like read and write barriers everywhere and thus 
> will never be in D's GC.
>
> - Jonathan M Davis

Yeah I thought it would have issues, thanks for your feedback!

I'll see if I can come up with a better idea that doesn't break 
as much stuff.