What's the go with the GC these days?

[Neia Neutuladh]

On Mon, 07 Jan 2019 14:53:50 -0700, Jonathan M Davis wrote:
> Given that sort of situation, I don't see how we can have the
> GC accurately track whether objects are thread-local or shared. Casting
> is just too blunt an instrument and allows too much.

This is exactly the situation I brought up in the post you're replying to. 
I explained what the solution is in the post you just replied to. That was 
in fact the entire point of that post.

It requires a number of careful steps. It's not automatic. It's *mostly* 
automatic, and you can wrap the rest in a library. But it's expensive and 
it makes it easy to write incorrect code.

To review:

When you cast to shared, the thread-local GC pins the thing as shared. It 
also finds every bit of its memory that you can reach from that object, the 
same way as if it were doing a mark/sweep collection, and *that* is also 
pinned as shared.

When you are modifying an object that's had shared cast away, you need to 
tell the GC not to run, or you need to pin objects-that-will-become-shared 
temporarily (for instance, by keeping local references to them).

When you are done modifying an object that's had shared cast away, you 
need to cast it back to shared.

This is not a good solution, so D isn't getting a thread-local GC that 
eliminates stop-the-world unless someone else comes up with a cleverer 
solution. On the other hand, it doesn't have a cost for casting away 
shared as such; casting shared(T) to const(T) is totally free.