It's 3 years old in a field that sees a lot of work. It also only focuses on free/OSS GCs. E.g. there's some pretty innovative stuff from Azul.
It's tempting to look at GC benchmarks and pick. But the only solution is to benchmark production with observability tools. Fine tuning GC parameters can completely change the performance picture. Also, priorities can be completely different once in production. E.g. performance or even memory overhead might not be as important as pause times.
I'd like to know that rather than ignore their existence. I worked with companies that swear by Azul for huge workloads, I'm curious if that expense is still justified.
That needs further elaboration, also in which way they would be better or best? While they might be fundamentally different (JVM will use only conservative GC, while Lisp runtime support allows and might favor precise GC), I for one would be very surprised if collectors with the highest throughput or least latency are found in a runtime support system for a programming language used by academia thirty years ago, rather than in one used by profit-oriented organizations for large data systems or games.
And while, e.g. SBCL is used commercially (google flights comes to mind), its GC isn't its forte.
> for a programming language used by academia thirty years ago, rather than in one used by profit-oriented organizations for large data systems or games.
I think that's a misconception. Common Lisp was designed as a language for Research & Development (R&D) and deployment of (often complex) applications on a wide variety of hardware.
There were/are a bunch of demanding applications developed, which were/are in commercial use:
* scheduling systems used by train services, airports and airlines
* image processing applications (like analysis of satellite images)
* CAD systems for aircrafts and cars (prominent users were Boeing, Airbus, Ford, ...).
* verification of cpu designs
* databases, typically object-oriented and graph databases
Typically GCs needed to work in interactive systems with very little user interruptions by GCs (incremental GCs) and in long running applications with large data sets.
Generally Lisp has less new commercial users than years ago and Java has many times more commercial users. There has been done a lot of GC progress in the context of JVM garbage-collectors. But it's not that commercial Lisp vendors had no industry users...
Franz Inc, a commercial Common Lisp vendor, has documented its GC:
He probably means Allegro CL which is in my experience the best one.
All the OS Lisp GCs are stuck in the 80s and honestly not very good. The one in LispWorks is pretty good though but I wouldn’t call it state of the art. It just works.
I listened to it for 5 minutes and I'm genuinely impressed by what the LM did. Especially the metaphores/comparisons it came up with. However it would be much easier to follow if it were accompanied with a slide show. Also, the plentyful 'awesome's and 'gotit's in between make it easy to be recognized as being artificially generated.
It's tempting to look at GC benchmarks and pick. But the only solution is to benchmark production with observability tools. Fine tuning GC parameters can completely change the performance picture. Also, priorities can be completely different once in production. E.g. performance or even memory overhead might not be as important as pause times.