A Performance Comparison of Modern Garbage Collectors (2021) [pdf] | Hacker News Reader

A Performance Comparison of Modern Garbage Collectors (2021) [pdf]

rodrigo-bruno.github.io

56 pointsmfiguiere13 comments

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.

Also JVM only. Some best GC's are elsewhere, in Lisp eg

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.

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.

How does one go about testing how good a GC is or isn't?

I'm most interested in SBCL and JVM.

I would call the LispWorks GC also superb, and it's even open source!

There's Cyclone Scheme, though I don't know how good its GC is in practice: https://justinethier.github.io/cyclone/

Also I would expect a programming language used by enterprise to do fewer experiments with the GC than a language worked on in academia.

> 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:

https://franz.com/support/documentation/gc.html

Non-OSS GCs are uninteresting.

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.

> It's 3 years old in a field that sees a lot of work

Including generational ZGC, kind of the holy grail of GCs.

I created a podcast of the document generated with NotebookLM in case someone wants an overview before checking it:

https://notebooklm.google.com/notebook/b01ebf44-9406-4ba6-be...

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.

Reply on news.ycombinator.com