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

[Robbin Ehn]

Hi Dean,

unloaded happens in a safepoint (or with zgc after) when it is safe to unload. 
Since we do not safepoint when creating a nmethod we know that methods marked 
for unloading must have been created before that safepoint.
And if we can unload a method it must not be on any stack.
Sweeper can go directly from unloaded to zombie.

Thanks for having a look!

If Erik cleans this up a bit, that would be nice :)

/Robbin

On 9/13/19 12:54 AM, dean.long at oracle.com wrote:
> Hi Robbin.
> 
> I like the new CompiledMethod_lock.  I had some concerns with 8224674 about 
> races between make_not_entrant and make_unloaded, so I was half expecting 
> CompiledMethod_lock to be used at a higher level than Patching_lock and protect 
> the whole call to make_not_entrant and make_unloaded.  Does make_unloaded need 
> to use CompiledMethod_lock at all?
> 
> dl
> 
> PS - Erik said he would file a RFE to refactor/cleanup make_not_entrant and 
> make_unloaded, but I can't find it.
> 
> On 9/12/19 4:21 AM, Robbin Ehn wrote:
>> Hi, here is v3, addressing Patricio's and Dan's review comments.
>>
>> Inc:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>>
>> Passed t1-5, doing some more testing also.
>>
>> Thanks, Robbin
>>
>> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>>> Hi, hotspot-dev was the intended list.
>>>
>>> Thanks, Robbin
>>>
>>> On 2019-08-28 09:30, 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
>>>>
>>>>
>