RFR(m): 8221734: Deoptimize with handshakes

[Robbin Ehn]

Hi Dean,

On 4/25/19 9:39 PM, dean.long at oracle.com wrote:
> I don't pretend to understand the biased locking changing :-)  Could you explain 
> the need for CompiledMethod_lock, and the other lock rank changes?

To iterate the compiled methods we need to hold CodeCache_lock.
(since we do this outside of a safepoint)
To be able to make a compiled method not reentrant it must be protected by a
lower ranked lock. So we protect the compiled method with this new lock instead
of Patching_lock (higher ranked).

> 
> Replacing
> 
> 1089 if (_method->code() == this) {
> 1090 _method->clear_code(); // Break a cycle
> 1091 }
> 
> 
> with
> 
> 
> 1087   Method::unlink_code(_method, this); // Break a cycle
> 
> doesn't look equivalent.  The new unlink_code has a stronger check, also 
> checking the entry point.  I'm not sure that's OK here.

Thanks, yes. I had a slightly different version before.
I'll go over this again.

> 
> In Method::Method(), don't we want to be able to initialize these fields without 
> grabbing CompiledMethod_lock?

This should just be an uncontended cas.
So I went with simplicity, disregarding this small overhead.
Let me know what you feel about that.

I'll send out a new updated and tested version next week.

Thanks!

/Robbin

> 
> dl
> 
> On 4/25/19 5:05 AM, Robbin Ehn wrote:
>> Hi all, please review.
>>
>> Let's deopt with handshakes.
>> Removed VM op Deoptimize, instead we handshake.
>> Locks needs to be inflate since we are not in a safepoint.
>>
>> Goes on top of:
>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-April/033491.html 
>>
>>
>> Code:
>> http://cr.openjdk.java.net/~rehn/8221734/v1/webrev/index.html
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8221734
>>
>> Passes t1-7 and multiple t1-5 runs.
>>
>> A few startup benchmark see a small speedup.
>>
>> Thanks, Robbin
>