[MLton] cvs commit: critical sections during thread switch

[Matthew Fluet]

> > So, it seems to me that for stack resizing, we ought to keep
> > stackNeedsReserved as is -- there's no sense in breaking the
> > mutatorStackInvariant on heap stacks if we can preserve it.
>
> It does cost space in every paused thread, which could be bad if
> maxFrameSize is large.

True.

> How about treating the current stack as a special case in forward?
> For all the paused stacks, either leave the stack alone or shrink the
> stack while keeping mutatorStackInvariant or (used <= reserved) true,
> depending on which we decide is better.  For the current stack, if we
> are not in a minor gc and the stack needs to grow, we could grow it
> right there in forward.  That would be nice because it would avoid
> recopying the stack later in growStack after the GC.  It would also
> avoid wasted space in the old generation for the dead stack.  Also, it
> would let us request less space in doGC than we are now.  Instead of
> requesting
>
> 	stackBytes (s, 2 * s->currentThread->stack->reserved)
>
> we only need to request
>
> 	stackBytes (s, 2 * s->currentThread->stack->reserved)
> 	- stackBytes (s, s->currentThread->stack->reserved)
>
> That is, we only need the additional space that forward will use to
> to skip over reserved space for the stack.

Turns out this isn't quite right.  If we start off with a very small stack
(eg., the stack saved at the beginning of the program) that was copied
with reserved == used, then just doubling the reserved might not be enough
to ensure the stack invariant.  It just means that we need to take

stackBytes(s, max(2 * s->currentThread->stack-reserved,
			stackNeedsReserved(s, s->currentThread->stack)))

as the size of the new stack.

> Thread_switchTo in basis/Thread.c does set bytesNeeded before invoking
> GC_switchToThread, so I don't see a problem there.  However, it's
> confusing having thread switching behavior split across these two
> functions and I don't see any reason for it.  Maybe we could fold
> Thead_switchTo into GC_switchToThread?

I don't see any reason not to.