Parallel garbage collection for SBCL (2023)

by tosh • 2 years ago

31 6 2 years ago

heisig• 2 years ago

This paper is from last year, and a lot of interesting things have happened in the meantime:

- The parallel garbage collector is now part of SBCL, but not yet the default. Enabling it is attractive, though, because it has roughly twice the throughput.

- The SBCL maintainers used the parallel GC as reason to make SBCL's memory management overall more modular. This process is still ongoing, but experimenting with different GC strategies on SBCL has never been easier.

- Another GC is already in the works that has virtually zero pause times. Once this is merged, we can finally bury that old myth that Lisp systems stutter (if it hasn't already been buried by the presence of video games written in Lisp, like Kandria)

The parallel GC is an amazing achievement by Hayley Patton. We SBCL users cannot thank her enough for her outstanding work!

throw10920• 2 years ago

The parallel garbage collector is now part of SBCL, but not yet the default.

Why is it not yet the default? Higher latency, not yet tested enough, or something else?

hayley-patton2• 2 years ago

It's not always faster, so making it the default could cause regressions; it seems pretty stable now but the default (gencgc) had a head-start of a few decades for bug finding (and making).

nemoniac• 2 years ago

How can you enable it? It's not obvious from the compilation instructions.

hayley-patton2• 2 years ago

Compile SBCL with the command ./make.sh --with-mark-region-gc and the resulting build will use the mark-region GC. (Picking the GC at start-time instead of build-time would be very nice, but technically hard to pull off unfortunately.)

Jach• 2 years ago

Also don't forget to clear your FASLs since they're not compatible. e.g. remove ~/.cache/common-lisp/sbcl-2.4.4-linux-x64/ and ~/.slime/fasl/

Parallel garbage collection for SBCL (2023)

Related Stories