What's the go with the GC these days?

[H. S. Teoh]

On Mon, Jan 07, 2019 at 06:59:10PM +0000, Russel Winder via Digitalmars-d wrote:
> On Sun, 2019-01-06 at 13:28 -0800, Walter Bright via Digitalmars-d wrote:
> > 
> […]
> > 1. Java has a very constrained interface to C, with a lot of rules
> > to follow, mainly so the GC is not corrupted. D, being a systems
> > programming language, simply does not have that luxury.
> 
> I understand that the Java language and its heap are very different
> from D, so the context and constraints are different. I am assuming Go
> is the same, though a priori I would think less different to D than
> Java. My concern (if it can be called that) is that the JVM folk and
> the Go folk spend a lot of time finding new and/or improved GC
> algorithms, whereas in D there appears to be no movement from an old
> and simple GC.

IOW it's more of a matter of perception than an actual technical
issue then?  And just FYI, there *have* been gradual improvements to D's
GC over the years, even if they are not ground-breaking ones.

In any case, as Walter said, Java / Go / similar languages impose quite
a lot of restrictions on what the programmer can do, which gives the
language implementors many more assumptions they can work with.

D pretty much gives the programmer free rein, except perhaps under
@safe, but even then, the restrictions are pretty minimal and nowhere
near the managed languages.  This leaves the language implementors very
little room for maneuvre, meaning that any prospective GC algorithm for
D is constrained by being unable to make the same assumptions that a
Java or Go GC can take for granted -- in fact, unable to make many
assumptions at all.  Naturally, this also rules out a lot of algorithms
that could otherwise be applicable, and makes finding a significantly
improved algorithm a very challenging task.  (And that's assuming said
significantly improved algorithm exists at all, under D's operating
conditions.)


> > 2. Let me know when Java lets go of write barriers!
> 
> G1 GC certainly avoids write barriers whenever it can.

The stickler is in "whenever it can".  Currently, Walter is operating
under the premise of "no write barriers *at all*".  Whether or not this
is a tenable stance as far as GC improvement is concerned remains to be
seen, but being able to fallback to write barriers occasionally
represents a completely different ballpark to having *zero* write
barriers, *anywhere*.  It may sound like a subtle difference, but it
makes a world of difference as far as GC algorithms are concerned.


> I do not know the details, but there are conference papers out there
> looking at avoiding write barriers at all costs in the newer GC
> algorithms.
[...]

If there are any GC algorithms that require no write barriers at all and
still offer the same benefits as a modern generational GC, I'm sure
we'll be jumping all over it in no time at all!  Assuming that it
doesn't make other assumptions incompatible with D, that is.


T

-- 
The best compiler is between your ears. -- Michael Abrash