LispWorks has a lot of features in its GC. Years ago it was used in a demanding telco application, an ATM switch. It was also used on a space mission experiment. Generally the runtime is very very nice.
Franz Inc uses Allegro CL in a large database. They tuned the GC quite a bit for that. But there were also other GC demanding applications on Allegro CL, for example in CAD and 3D design. They are now working on a concurrent GC, something which is still rare in the Lisp world.
Mostly because there are very very few people in the world who are able to develop such a complex thing for Lisp (or similar runtimes). Since the market is relatively small and many applications are not overly concurrent, there is very little money to support the development.
I am guessing[1] that GCs are easier to code correctly without the concurrency and that a GC language is already expected to be slower so it doesn't make sense to do a concurrent GC. Also possibly, the language doesn't support concurrency well. Like a Python or Ruby.
[1] just an educated guess. I have no real knowledge of GCs other than skimming how they work in articles and runtime/language docs.
It doesn't actually implement concurrent GC, although what it does implement is far simpler and has a similar effect (low latencies) as concurrent GC.
Each Erlang process has a separate heap that is collected independently; because the process heap is usually small a stop-the-process collection does not take much time.
The downside is that sending messages between processes requires copying all the data that is sent between process heaps.
I've worked a lot with LispWorks and tuning the gc had the same method of programmatically calling a full GC after every N operations. We also found setting the gc threshold to high amount helped a bunch.
Supposedly they have a concurrent GC in the works but I haven't played with it.
Anyone here has any experience with the GCs of Allegro or LispWorks or any other commercial Lisp implementations?