There's been a lot of SBCL-related activity since the last release. Some committed, some work-in-progress, and some outside core SBCL but still tightly coupled to it. For example:

• The last of the GC changes I've been committing since 0.9.4 are finally in. These should be especially useful to people with a modern x86/x86-64 processor running Linux (the GC used a slightly different implementation strategy on BSDs; somewhat to my surprise the benchmarks show a modest speedup for the new version on FreeBSD).

• James Bielman has done a couple of iterations on a patch that adds the option to dump a self-contained executable with save-lisp-and-die. Basically it works by just concatenating the SBCL runtime (the 200kB executable) and the produced core file. This is in contrast to the patches that Timmy Douglas made last August, which did some fancy manipulation to embed the core in an ELF section. While the latter choice is ideologically and technically sounder, the former one has the benefit of being simpler to implement and much simpler to port. It even works on Windows.

• Speaking of which, there's been impressive progress on the win32 port. I won't go into the details (read sbcl-devel or join #lisp on freenode for that), but at least Alastair, Christophe, James, Luis and Rudi seem to have put in a lot of effort on it. I'm also slightly nauseated by the Windows API details they've been flogging on #lisp.

• Gábor Melis has made significant improvements to the constraint propagation code in the compiler.

• Cyrus Harmon has fixed a huge amount of callback bugs in the PPC port. And also made some tests that discovered some similar problems on x86-64, which I then felt honour-bound to correct. Additionally I fixed a x86/x86-64 bug that lead to callbacks not working properly when saved in a core.

• Actually many other small x86-64 code-generation improvements and backend cleanups too, some contributed by Lutz Euler and some by me.

• David Lichteblau is working on sb-heapdump, a program that can do a selective memory dump of a running SBCL image. The idea is that the memory dump can be loaded faster than a FASL thanks to dropping a lot of the generality that a FASL has. "Just" load the dump into memory and go through it once to fix up various references. At the same time it'd be more usable than a core since you can dump just a subset of the image (e.g. "dump package FOO") and later load that image into a compatible core. Definitely cool stuff, though getting all the small details right is going to be tricky.

  David has made a preliminary version of sb-heapdump available.

In all likelyhood I forgot something or someone. Apologies for that.