[MLton] cvs commit: improved GC structure

[Stephen Weeks]

> There are a few functions in /runtime/basis/Thread.c that do nothing but
> dispatch to their corresponding GC_ functions.  Maybe they should all be
> made into calls to GC_ functions.  And maybe more of them should be
> prims, since they could easily be implemented in ssa-to-rssa.

I'm not sure it's a good idea to make things prims only for that
reason.  It's good to add a prim if the optimizer can simplify it in
some way or if it's required for the optimizer to understand the
program.

Maybe what we need is a way to access gcState from SML so that we can
use _import and call the GC_ functions directly from the basis
library.

> > Since major GCs are infrequent, why not instantly shrink all paused
> > stacks to minimal size?  Or maybe shrink them by a factor of two each
> > time, until they drop below mutatorStackInvariant, at which point drop
> > them to minimal size?
> 
> Are you suggesting that we only shrink stacks in a majorGC?

I wasn't thinking of that.  BTW, we shouldn't mislead ourselves -- for
many programs, the program will not be tight on heap space and the
generational GC will never be turned on.

> (And I presume that there would be a way of also shrinking in a
> markCompact majorGC.)

Yes that should be doable.  It isn't done now unfortunately.

> Or, maybe you're just noting that most threads that we see will
> be tenured, so they'll effectively only be seen during a majorGC.

That's what I was thinking.  A thread will be initially created in the
nursery, and then copied to the old generation at the first minor GC.
When a thread's stack is grown, it is always grown into the old
generation.  So, after its first minor GC, the thread will only be
seen during major collections.

But again, for the (many) programs that don't use generational GC,
every thread will be seen on every GC.

> I don't want to drop stacks to minimal size too quickly, because that will
> end up essentially forcing a GC at every switch to a thread that lived
> through a GC.

It does only force a minor GC, which will only do something if the
program is using generational GC.  But yeah, that could be bad.

> So, I like the suggestion of shrinking by a factor of two until they drop
> below the mutatorStackInvariant and then drop them to minimal size.

OK.  How about making the factor a runtime parameter,
"thread-shrink-factor", with a default of 0.5 and a range of [0,1]?
That way, people can force very aggressive shrinking or no shrinking
at all if they want.