[MLton] cvs commit: improved GC structure

[Matthew Fluet]

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

Well, for things like Thread_current and related functions that just
mediate access to the gcState, it seems like a lot of overhead to make a C
call to do the simple memory offset access.  And we support a lot of this
stuff in the backend now anyways.

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

I'm confused here.  Regardless of what GC policy is in effect, attempting
to run a thread that has it's reserved == used will need to grow the
stack.  Currently, the way we do that is by doing a GC.  That's going to
incur some minimal cost (like enter/leave, some system calls,etc), which I
thought we wanted to avoid for the "fast path" thread switch.

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

That's seems like a fine suggestion.