another limit check bug

[Matthew Fluet]

> > But if we are in C code then a context-switch isn't going to happen.
> > Is this just a matter of changing the check
> > 	frontier + (b) > gcState.limit
> > to
> > 	frontier + bytes > gcState.stackLimi
> 
> I don't think so.
> 
> Ignoring the code, every thread that is paused will need to check for
> some amount of free space when it resumes.  That amount can either be
> embedded in the code or in the thread data structure.  If the amount
> is fixed, then it can be embedded in the code.  However, if the amount
> is variable, then it must be in the data structure, since two threads
> can share the same code, right?

This bug doesn't exist in the native codegen, because the "loop" for a
limit check at array allocation starts at the computation of the number of
bytes needed for the array.  Hence, the variable allocation size is in the
thread data structure by virtue of the fact that the array size is an SSA
variable, live across the limit check, hence in the stack -- which is part
of the thread data structure.

This causes the problem that started me looking at these issues.  I want
to put all the handling of gc checks in the LimitCheck emitter, but when
this is inside the limit check loop, we never escape the limit check loop
when -gc-check every.

> As to putting the while loop in GC_gc -- that is a separable issue,
> and a bad idea I think.  Won't it cause problems by leaving around a C
> stack frame for every thread?  We don't want that.  

I don't get this.  There aren't C stack frames per MLton thread.  I'm
simply proposing adding:

	s->currentThread->bytesNeeded = bytesRequested;
	do {
...
	} while (s->frontier + s->currentThread->bytesNeeded > s->limit);

to GC_gc, where ... is the entire body of what's currently in GC_gc;
(including enter(s) and leave(s), which takes care of resetting limit when
handlers are pending).  We'll enter C via a C call to GC_gc, and we'll
leave C when GC_gc returns.

> I propose to leave
> the loop in the code, but have the limit check set and refer to a
> per-thread data structure.  Then, the only runtime change is to add
> another field to GC_thread.

I could do this as well.  But, I don't think there is a problem with the
above solution.  Doing the loop in code has the option of making
non-looping limit checks on a per-program basis.