Threads and suspending

Hi Rhys,

We may have to consider having checks on backwards branches again.  In order
to coordinate GC behaviour, we need a safe way to suspend threads.  I don't
think Win32's SuspendThread or using signals will ever be safe.  What we
need to do is, like Thread.Abort, have GC-suspend "checks" at various points
of code (a "hey, does the system want me to suspend, abort, etc?").  
Currently, that check is done at the end of methods (since I judged that
responses to aborts and suspends don't need to happen immediately).  This
needs to change if we need to suspend for GC reasons.

What I propose is that we think about adding a check for ILExecThread::
managedSafePointFlags at every backwards branch and at the end of function
calls.  The managedSafePointFlags field is non-zero if a request (such as
suspend/abort) is requested.  This overhead will allow us to reliably
suspend threads for garbage collection in a reasonable amount of time.  The
overhead will cause loops like "for (;;);" to act as slowly as "while
(obj.field);" but will allow us to implement a reliable and stable copying
collector!  I think for most applications, the overhead of the flag check
will be far outweighed by the contents of the loops.

This is the way ROTOR does it and after talking to gadek, this is the way
SableVM does it too.

The cool thing about polling (opposed to using signals) is that threads will
always be suspended at safe points and stack-stable points.  We never had to
scan for references on the computation stack as there will be none so we
only have to scan for the local arguments and local vars (and we know,
statically, how they are laid out).

As for native code (and code that's currently in a blocked/wait/sleep/join
state), I think they just need to be politely "asked" to suspend themselves
after they return from native code.

What do you think?

We don't have all the answers yet but I think we/I have enough to start
considering thinking about starting to contemplate writing a new GC ;))).

^Tum