[MLton] More on parallelism

[Stephen Weeks]

>     a) Move various fields of the struct GC_state (runtime/gc/gc_state.h)
>     which are used by ML code (in particular, frontier, limit, stackTop,
>     stackLimit, exnStack, atomicState?, limitPlusSlop, stackBottom) into
>     their own struct which should be accessible in some OS-thread local
>     manner.  The GC_state will likely maintain a linked list of these
>     structs to keep tabs on all of the running ML code.

An array might work better.  It could be sensible to choose a fixed
number of ML threads (say, equal to number of processors) at program
start time.  Using an array will give constant-time access to
thread-local data structures.

>     b) Rework the GC code to parcel out the nursery into individual
>     nurserys; rework the GC entry code so that when one mutator exhausts
>     its private heap space, the other mutators are stopped (by setting
>     their frontiers to 0, which will trigger them to enter the gc).  This
>     will allow a single-threaded GC to garbage collect the world, reset the
>     various nurseries, and start up the mutators again.

I was actually thinking that when one thread runs out of nursery
space, it would stop only the thread with the most free nursery space
remaining.  They would then split that space and continue.  That way,
one doesn't have to stop all threads.  At some point, of course, the
nursery splitting doesn't buy enough because the free space gets too
small, and then one stops all threads and does a major GC.  But then
one really needs the major GC at that point.

It's a separate issue whether the major GC is parallelized or not,
although I would certainly start with our current single-threaded
one.