[MLton] GC help

[Stephen Weeks]

> 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%.

That is more variation than I would expect.  It does make sense that
one can do better by telling the program that it can use a lot of
memory, since the runtime doesn't have to spend time resizing the
heap, and may also have a high ratio of heap size to live data much of
the time.  But I wouldn't expect things to get as bad as 60%.

> Do you know why this is the case?

It's tough to guess.  The code in MLton that decides when to change
the heap size, how much to change it by, and what collection strategy
to use is fairly brittle.  It simply uses hardwired constants and
doesn't feedback any measurement of GC effectiveness while the program
is running.

You could send a (possibly abbreviated) log of a run of the program
with "@MLton gc-messages gc-summary --", both with and without the
fixed heap.  The gc-messages might show us some obviously stupid
resizing decisions that the runtime is making.  With no data, my only
guess is that it grows the heap beyond the point (1G) where it can do
a copying GC, and gets stuck in a mode where only mark-compact GC is
possible.  Mark-compact is much slower than copying.