[Haskell-cafe] Re: Real-time garbage collection for Haskell
marlowsd at gmail.com
Tue Mar 2 09:17:41 EST 2010
On 01/03/2010 17:16, Sebastian Sylvan wrote:
> On Sun, Feb 28, 2010 at 5:20 AM, Luke Palmer <lrpalmer at gmail.com
> <mailto:lrpalmer at gmail.com>> wrote:
> I have seen some proposals around here for SoC projects and other
> things to try to improve the latency of GHC's garbage collector. I'm
> currently developing a game in Haskell, and even 100ms pauses are
> unacceptable for a real-time game. I'm calling out to people who have
> seen or made such proposals, because I would be willing to contribute
> funding and/or mentor a project that would contribute to this goal.
> Also any ideas for reducing this latency in other ways would be very
> Since we're talking games here (my profession), I'd point out that it
> would be cool to be able to supply "hints" to the GC about when might be
> a good time to do a GC (without unconditionally forcing it), games in
> particular have some pretty specific properties that may be exploitable.
> Presumably a non-trivial portion of the objects copied from the
> nursery/G0 are actually short-lived objects that just happened to have
> their short life-span overlap with the collection. So really, copying
> them to the next generation is a "mistake" in some sense.
There's a technique we use, that mitigates the effect of this to some
extent, called "aging". The idea is that an object is only promoted if
it survives at least N GCs in the young generation. Typically N=2 is a
good value, so an object that is allocated just before a minor GC will
be copied, but probably not promoted unless it survives all the way to
the next GC. You can also use fractional values of N and in fact you
should measure N in terms of bytes allocated rather than GCs. In GHC
6.12.1 you can tune the amount of aging with +RTS -T<n>, but I removed
the option in 6.14 in order to make the GC implementation simpler, we
now have a fixed aging -T2 aging policy. In practice other values were
very rarely any better, in fact.
> For games,
> though, we have a very good point that occurs regularly where we know
> that all/most short-lived objects will no longer be referenced - at the
> start of a fresh frame.
System.Mem.performGC is your friend, but if you're unlucky it might do a
major GC and then you'll get more pause than you bargained for.
More information about the Haskell-Cafe