1. 22
  1.  

  2. 2

    TL;DR: They added a mark-and-sweep collector as an older-gen collector, and use the existing semi-space collector for young-gen.

    Maybe I’m getting old and tired, but isn’t that pretty much working at the stone-age of GC design? Just reading this makes me disappointed of what they did before. :-(

    1. 1

      Well, changing the GC in a programming language is quite a bit deal, I think.

      Didn’t golang also go for “stone age” mark & sweep with great success?

      1. 0

        Well, changing the GC in a programming language is quite a bit deal, I think.

        It depends, it gets easier the third or fourth time. :-)

        Didn’t golang also go for “stone age” mark & sweep with great success?

        Possible; achieving “stone age” is probably seen as a “great success” in a pre-stone age language like Go though. :-)

      2. 1

        If true, then yeah it’s not cutting-edge by any means. Just maybe an incremental improvement over what they had.

      3. 1

        Little question:

        the runtime of a “typical” server application may regress by at most 10%

        This means regress to the current GC, correct?

        1. 2

          Yes, I’m missing a benchmark here though – 10% worse is reasonable when going for smaller pauses, although I don’t really see where they might lose that much performance in their specific case of adding a mark-sweep collector in addition to the semi-space collected nursery.

          (Though I’m also not really seeing how the exercise as a whole puts them on a path toward lower latency.)