RFR(m): 8221734: Deoptimize with handshakes

[dean.long at oracle.com]

I don't pretend to understand the biased locking changing :-)  Could you 
explain the need for CompiledMethod_lock, and the other lock rank changes?

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.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190425/b3feffd9/attachment.html>