3 ms·
GC can be hard with single threading as well. Even if you don't have concurrency to worry about, it still has to be incremental - meaning to do its work in smal
by bad_user 11y ago
GC can be hard with single threading as well. Even if you don't have concurrency to worry about, it still has to be incremental - meaning to do its work in small batches and provide a guarantee that the process doesn't get blocked for more than X millis.
Also, if you can rely on the data-structures stored in your heap to be persistent, then you can tune the GC for it. The problem is that you need to make assumptions about the life-cycle of those data-structures. For example, the persistent data-structures being used in Scala or Clojure can be pretty heavy for the JVM's garbage collectors because they tend to produce junk that is neither short-term or long-term, thus invalidating the assumptions with which the JVM was built with. And generally that's OK, because the JVM's GCs can cope pretty well and if the need to optimize arises, well both Scala and Clojure are hybrids (just like OCaml), so you can just use mutable stuff if by profiling you see problems. So the theory is known and a decent concurrent GC can be built.