What are your hopes for the future D GC

[Jonathan M Davis via Digitalmars-d]

On Friday, June 30, 2017 20:58:56 Dmitry Olshansky via Digitalmars-d wrote:
> On 6/30/2017 7:54 PM, H. S. Teoh via Digitalmars-d wrote:
> > On Fri, Jun 30, 2017 at 09:14:41AM +0300, Dmitry Olshansky via 
Digitalmars-d wrote:
> >> On 6/29/2017 10:19 PM, Random D user wrote:
> >>> I just got curious, after reading the GC analysis blog post. What
> >>> kind of features people generally would want for the GC (in the
> >>> distant murky future of 1999)?
> >>>
> >>> Here's some of my nice to haves:
> >>>
> >>> 1. Thread local GCs. D is by default thread local, so it kind of
> >>> would make sense and goodbye stop everything GC.
> >>
> >> Yes, yes and yes. The moment we fix the spec and code that casts
> >> shared to TLS at will.
> >
> > Hmm.  I'm not familiar with the intricacies of shared; could you
> > elaborate on how casting from shared causes problems with a thread-local
> > GC?  Or is the problem casting *from* shared?
> >
> >
> > T
>
> Seems like my first post went into aether, sorry if double posting.
>
> The problem is generally with transfer of things from one thread to
> another. Currently this is done with good natured casts such as
> assumeUnique. The GC needs to be in the know of what is transferred to
> who.

Yeah, the compiler would have to insert additional instructions when casting
to or from either shared or immutable. Otherwise, a thread-local object
could easily be on a thread other than the one that it was created on. Also,
you have the issue of it being easier to construct something as thread-local
or mutable and then making it shared or immutable, in which case, it's fine
for the object to be treated as shared or immutable by most of the code, but
it means that its type would no match the GC that was used to allocate it.
Passing the object between GCs as part of the cast would almost certainly be
required to solve that problem.

However, you do have the issue that in order to operate on shared data, you
typically have to cast the object to thread-local (after locking the
appropriate mutex, of course) and then doing stuff on it as thread-local
before getting rid of all of the thread-local references and releasing the
lock. And moving the object between GCs for that would be an unnecessary
performance hit.

And all of that is when you're just talking about code that is reasonably
well behaved and not even considering the consequences of folks being idiots
about casting to or from shared and shooting themselves in the foot by
having shared objects passed around as thread-local or vice versa without
doing the appropriate stuff with mutexes - and it doesn't take into account
all of the cases where folks keep using __gshared when they should be using
shared, potentially resulting in fun problems if the GC is then
thread-local.

And IIRC, Daniel Murphy pointed out to me at one point that there was some
issue with classes that even shot the idea of transferring objects between
GCs in the foot. But unfortunately, I don't remember the details now.

In any case, past conversations on this have led me to believe that while it
would theoretically be nice to be able to take advantage of the fact that
D's type system marks objects as being shared or thread-local and have
separate GC's per thread, it isn't actually something that would be tenable
in practice, because the corner cases are too costly to deal with if not
actually outright intractable.

A more advanced type system that has some concept of thread ownership might
be able to solve the problem, but that would almost certainly complicate the
language too much to be worth it.

- Jonathan M Davis