What's the go with the GC these days?

[Jonathan M Davis]

On Monday, January 7, 2019 3:27:15 PM MST Neia Neutuladh via Digitalmars-d 
wrote:
> 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.

Well, then I clearly read over it way too quickly.

> 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.

Yeah, such a solution wouldn't fly. Basically, you're talking about having
to have a way to tell the GC that you're moving stuff between threads, and
that would be so error prone that it's not even funny. It's already
problematic enough to get code that deals with sharing data across threads
right as it is.

If we could solve the forking problem on Windows so that we could actually
have a cross-platform concurrent GC like the Linux one that Sociomantic has
used, then that would likely give similar benefits (if not better) without
having to muck with the type system. I forget exactly what the
stop-the-world pause times were, but they were pretty low. If a thread
really couldn't afford to be stopped at all, it would still need to be
separate from the GC, just like now, but that would be true of a solution
that involved thread-local heaps as well.

In any case, it's issues like these which definitely make it much harder to
drastically improve D's GC. We have much worse constraints to work under
than languages like Java, and we don't have the same kind of manpower trying
to improve the situation. But at least D is set up in a way that works quite
well with minimizing heap allocations - especially with the idioms that are
typical in idiomatic D.

- Jonathan M Davis