[MLton] GC help

[Umut Acar]

Thanks for the help with G.C., Stephen.  I have been playing with
various arguments and the MLton does seem to be doing a very nice job
overall.

I have been a bit puzzled by the "fixed-heap" parameter, however. When
I run my applications with @MLton fixed-heap 2040M, the percentage of
time spent by G.C. is very low (less than 5%), but if I use @MLton
ram-slop 0.98 instead then the G.C. time can be as high as 60%.

Do you know why this is the case?  (I would have expected MLton to
utilize the available memory automatically)


Umut


On 8/14/05, Stephen Weeks <sweeks@sweeks.com> wrote:
> 
> > My applications have lots of live data and use lots of side effects.
> > I would like to understand the effect that different G.C. policies
> > might have on the running time.
> 
> There is a little bit of info at
> 
>   http://mlton.org/GarbageCollection
> 
> The first thing to try is running your application with
> 
>   @MLton gc-summary --
> 
> This will tell you how much time is spent in GC, and break the
> collections down by type so you know which kind are happening.
> 
> What matters is not so much the absolute amount of live data, but the
> amount relative to the memory available.  By default, MLton is very
> aggressive in grabbing memory so it can keep a high ratio (16) of heap
> size to live data size.  This enables it to cost-effectively use
> copying collection.  Only when there isn't enough memory available
> does MLton switch to generational collection.  And only when memory
> gets really tight does it switch to mark compact.
> 
> If there's enough memory available, you should only see about 10-15%
> of your time spent in GC, and no further tuning will be required.
> 
> > Is there a way to turn generational collector off completely (use just
> > the copying collector)?
> 
> Yes, you can compile with
> 
>   -mark-cards false
> 
> This causes the mutator code to not insert card marking statements at
> pointer assignments.  Since the generational collector relies on card
> marking, it is thus unable to run.  -mark-cards false has the added
> benefit of not doing the card marking statements, although we've never
> measured a significant cost to them (more than a percent or two).
> 
> Beware in coming from the SML/NJ world, where the GC seems to cost a
> lot and occasionally exhibit pathological behavior (this from informal
> observations).  Card marking in MLton is very fast, and the
> generational GC is too.  So even in the odd circumstance when
> generational GC does kick in, you won't see the kinds of problems you
> might with SML/NJ.
> 
> > In general, what are the ways to control G.C.?
> 
> The documented controls are at
> 
>   http://mlton.org/RunTimeOptions
> 
> The undocumented controls are in processAtMLton() in runtime/gc.c in
> the sources.
> 
>   http://mlton.org/cgi-bin/viewsvn.cgi/mlton/trunk/runtime/gc.c?view=markup
> 
> Relevant undocumented controls are:
> 
>   copy-generational-ratio
>   grow-ratio
>   live-ratio
>   mark-compact-generational-ratio
>   mark-compact-ratio
>   nursery-ratio
> 
> You can use this to tune when (and whether) the GC switches between
> different collection strategies.  If you want details on any specific
> undocumented control and it isn't clear from gc.c, I can have a look
> and figure out exactly what's going on -- but I don't know them off
> the top of my head.
> 
> _______________________________________________
> MLton mailing list
> MLton@mlton.org
> http://mlton.org/mailman/listinfo/mlton
>