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!
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).
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.)
- 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!