[MLton] cvs commit: improved GC structure

[Stephen Weeks]

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

True.  What we need is general support for getting/setting components
of C structs.  For things like Thread_{finish,start}Handler, we could
get those now using an _import to access the address of gcState.

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

Right, except there is confusion about the meaning of the phrase
"doing a GC".  I took it to mean that an actual GC (major or minor)
was occurring, which is not necessarily true.  What is true is that we
call GC_gc.  And I agree, that is too slow for the fast case.

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

To be consistent with other settings in [0,1] it should be called
thread-shrink-ratio.