limit check insertion

[Matthew Fluet]

> > Well, I see tons of limit checks for 0 bytes in the resulting code; so
> > that seems a little wasteful.
> > 
> > I'm also not convinced that what's checked in solves the vliw problem.  I
> > can still trace around that loop and not encounter a non-zero limit check.
> 
> Recall that a limit check with bytes = 0 really means a check for LIMIT_SLOP
> bytes (currently LIMIT_SLOP = 512).  With -limit-check-per-block true, I would
> expect that most limit checks would have bytes = 0.  So, I think vliw is OK.

Forgot about LIMIT_SLOP.  This makes sense.

> > In a single-threaded world, yes.
> > In a multi-threaded world, we could make this work by keeping a
> > "bytesNeeded" field in GC_thread which would be set when the thread is
> > suspended.  When restarting a thread, the loop needs to use the
> > bytesNeeded. 
> 
> I like this idea.  Then, because the looping code is shared, we don't even have
> to worry about treating single- and multi-threaded programs differently with
> regard to the limit check loop.

Other than the fact that you always pay for the loop, which is what we're
currently paying for, so performance wise it shouldn't be any worse; in
fact, in the places where we really did need to loop, doing the loop in
the runtime will be slightly faster, because we won't be making a second
call from assembly.

> Anyways, I'm going to start on debugging simple.  Matthew, can you look at
> prodcons and mutex?

Sure, give me the non-deterministic programs. ;)