[simonmar]

We still have lots of tuning to do, I'll be looking in detail at what is going on during those pauses. This program is slightly atypical in doing quite a lot of old-generation collections though (you can see two in the graph), it has a low infant mortality and might benefit from a larger nursery size. (don't you love GC analogies? :)

[amalcon]

Interesting. So that's why "there are other, less picturesque examples that improve more."

Out of curiosity, does the GHC GC take advantage of the property that most data is immutable? Is it mutable from the perspective of the GC? I could easily see GHC playing with that constraint internally. Pure curiosity is at play here: I've never heard of a garbage collection scheme that takes advantage of immutability, but logically it seems like it should be possible.

[nominolo]

GHC has a comparatively expensive write barrier. That could be seen as taking advantage of immutability. The runtime system takes more advantage of purity, though. For example, it's safe to have certain races, because they will give the same result. Too much work duplication must be avoided, though, but that's much cheaper than excessive locking.

[simonmar]

Oh yes, immutability is crucial. Generational GC already makes you pay for mutation with a write barrier, and in our parallel GC we omit the locking when copying immutable objects, accepting that a few might get copied twice. In the new GC mutable objects become even more expensive. I don't think local GC is viable at all in a language with ubiquitous mutation.