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

[Robbin Ehn]

Yes, thanks, I closed as dup.

FYI: Fixing what ErikÖ mentioned about state going-backwards is causing a bigger 
change, partly because of pre-existing bugs.
That changeset is stabilizing so I'm hoping it will be done next week.

/Robbin

On 2019-09-06 22:12, Daniel D. Daugherty wrote:
> Robbin,
> 
> This RFR doesn't mention the following bug:
> 
>      JDK-8225351 assert failed: Revoke failed, unhandled biased lock state
>      https://bugs.openjdk.java.net/browse/JDK-8225351
> 
> which is still open. Part of me is wondering if it should be closed as
> a duplicate of:
> 
>      JDK-8226699 [BACKOUT] JDK-8221734 Deoptimize with handshakes
>      https://bugs.openjdk.java.net/browse/JDK-8226699
> 
> But the paranoid part of me wonders if this fix:
> 
>      JDK-8226705 [REDO] Deoptimize with handshakes
>      https://bugs.openjdk.java.net/browse/JDK-8226705
> 
> has that base covered... So I figured I would ask on the review
> thread to make sure...
> 
> Dan
> 
> 
> 
> On 8/28/19 3:30 AM, Robbin Ehn wrote:
>> 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
>>
>>
>>
>