RFR(L): 8226705: [REDO] Deoptimize with handshakes

[Robbin Ehn]

Hi all, please consider,

To get away from the issues of us revoking in the handshake, but before deopt
the locks get re-biased before we hit deopt handler, we instead revoke in deopt
handler.
The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after
that but before we start looking at the monitors, with a NoSafepointVerifier.

Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts
some pieces did not apply:
http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
So this is what was reviewed.

The rebase (merge conflict resolutions) and 8224795 bug fix :
http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/

Bug 8224795 fix is here:
http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html

After this we have the same functionally as the reverted change-set.

Here is the changes for doing the revoke in deopt handler instead:
http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/

This code was messy adding the deopt revocation in 3 places made it worse.
Here is a refactoring of that code. (also removed a dead method in biasedlocking):
http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/

And here is full:
http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/

Also a full squashed patch file:
http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch

Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
running.

Thanks, Robbin