Not having used them, I'd expect the Truffle implementations of Python and Ruby to do well, seeing as Graal handles #2-5 of moonchild's list. From there #1 might fall out. (Apparently the fancy GCs for #6 are only in the Enterprise Edition though?)

I'm working on a better, parallel but still far from Java state-of-the-art GC for SBCL <https://zenodo.org/record/7816398> - which presumably is some skin in the game.

Yeah, state of the art GC, but SBCL and ECL run circles on performance compared to any Java turd, even if being AOT compiled with GRAAL.

Just compare the Nyxt web browser with any Java monster out there.

Do they? I had to help SBCL with bounds checks (read: disable them) when porting the Java NonBlockingHashMap to Common Lisp. Perhaps still too micro- a benchmark, and I've indeed made turds with Spring, but the rest of HotSpot would do wonders on non-turd programs. (Would also expect Graal with JIT to be faster than AOT after warmup, but no experience there.)

Look at this real-time garbage collector for C++: https://github.com/pebal/sgcl

Is there any documentation on the algorithm used?

The Mark and Sweep algorithm with tri-color marking variation was used. There is no documentation yet, but I am happy to answer your questions ([email protected]).

self, javascript (v8), java (hotspot; generics are latently monomorphised according to hotness; also see 'invokedynamic'), apl (apl\3000)

I don't think you can say that java "doesn't use type annotations".

Well, technically you do have the var keyword now.

  var x = MyAwesomeClassFactoryBeanTemplate.getBean().getFactoryInstance().createNewMyAwesomeClass(foo, bar);

I am not super familiar with Java but that syntax typically implies type inference, which is not the same as not needing type annotations.

Not only is it type inference, it's limited to locally declared variables.