> Pascal Costanza wrote: > > > This was primarily for the lack of good parallel, concurrent garbage > > collectors in Common Lisp implementations. > > I'd be curious to know if there are particularities in CL itself that > make this difficult, or if it's simply because there's no manpower to > improve the GCs we have currently.
It's strictly a lack of manpower. Most CL implementations have GCs that were state-of-the-art 25 years ago: they're either mark-and-sweep or copying & generational, and have to perform all collection while application threads are paused (i.e. stop-the-world), hence the collection pauses that are proportional to the heap size. The newer GCs of Go and the JVM (ZGC and Shenandoah) are not generational and employ techniques such as pointer coloring and store/load barriers by instrumenting all object read/write operations instead of using virtual memory protection (which tends to have a non-indifferent performance penalty), and because they rely heavily on atomic operations to maintain heap consistency the stop-the-world phase is much shorter and only required to update the internal GC metadata. The result is that instead of 99th percentile pauses of 10+ seconds that we see with QPX or other allocation-heavy applications, these newer GCs show 99th percentile pauses of < 10ms, and perhaps medians going from ~500ms to 2ms (YMMV). Here's a pretty good description of the difference between the two new JVM collectors and how they compare to the older ones: https://www.youtube.com/watch?v=WU_mqNBEacw. -- Stelian Ionescu
