Correct long-standing thread status change bug.
If the stars aligned correctly (or you were running valgrind), it was
possible for a thread to change its status to RUNNING immediately after
having its suspend count incremented. The problem is that the thread
initiating the suspension regards the target thread as being in (say)
VMWAIT with sCount=1, which means its safe to kick off a GC. The target
thread thinks it's happily in RUNNING and can go do whatever it wants.
The fix is to move the status change so that it's guarded by the
suspension count mutex.
This shouldn't affect performance. The number of instructions executed
is about the same.
Also, the "self can be NULL" feature of dvmCheckSuspendPending had very
few customers, so we now skip that check and just require it to be set.
For bug 2309331.
Change-Id: Id512e16e321515a467c20b382c85017cef9cea4d
3 files changed
