RFR(m): 8221734: Deoptimize with handshakes

Robbin Ehn robbin.ehn at oracle.com
Tue May 21 09:48:24 UTC 2019


Hi Dan.

On 2019-05-21 00:49, Daniel D. Daugherty wrote:
> On 5/20/19 5:04 AM, Robbin Ehn wrote:
>> Hi all, please see this update v4.
>>
>> I have fixed the simplification Patricio talked about and David's nit.
>>
>> The interesting part is now the full diff of bias locking cpp file:
>> http://cr.openjdk.java.net/~rehn/8221734/v4/webrev/src/hotspot/share/runtime/biasedLocking.cpp.sdiff.html 
>>
>> It's very clean.
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8221734/v4/
>> Inc:
>> http://cr.openjdk.java.net/~rehn/8221734/v4/inc/
> 
> src/hotspot/share/runtime/biasedLocking.cpp
>      L640:   assert(mark->biased_locker() == THREAD &&
>      L641:             prototype_header->bias_epoch() == mark->bias_epoch(), 
> "Revoke failed, unhandled biased lock state");
>          nit - please reduce L641 indent by 3 spaces.

Fixed.

> 
>      L698:         assert(THREAD->is_Java_thread(), "");
>          nit - s/""/"must be a JavaThread"/

This method is restored, so I have no changes here.
I will skip adding the comment because Patricios biasedlocking changeset will
apply clean if I leave this method untouched.
So we fix this assert in his changeset instead.

> 
> src/hotspot/share/runtime/biasedLocking.hpp
>      No comment.
> 
> src/hotspot/share/runtime/deoptimization.cpp
>      L1321:     markOop mark = obj->mark();
>          Is now unused (which is good since it could get out of sync
>          with the one fetched in revoke_own_locks_in_handshake()).

Removed.

> 
> test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java
>      No comments.
> 
> No need to see a new webrev if you decide to fix the bits.

Thanks Dan!

I'll send out a v6.

/Robbin

> 
> Dan
> 
>>
>> I have seen no issues in T1-7, KS and other assorted testing.
>>
>> Thanks, Robbin
>>
>>
>> On 2019-04-25 14:05, 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
> 


More information about the hotspot-compiler-dev mailing list