RFR(m): 8221734: Deoptimize with handshakes

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue May 21 19:06:28 UTC 2019


On 5/21/19 6:27 AM, Robbin Ehn wrote:
> Hi all, please this update.
>
> Dean do you have any more comments?
>
> For some reason webrev don't shows whitespace fix in biasedLocking.cpp.
> But is clearly visible in:
> http://cr.openjdk.java.net/~rehn/8221734/v5/inc/webrev/open.patch

Also visible via the file's patch link:

http://cr.openjdk.java.net/~rehn/8221734/v5/inc/webrev/src/hotspot/share/runtime/biasedLocking.cpp.patch

I believe the default for webrev is to ignore leading and trailing white
space changes for most of the "diffs" that are generated. So a white
space change like this:

      < This is  the line.
      > This is the line.

will (likely) show up. :-)


>
> Inc:
> http://cr.openjdk.java.net/~rehn/8221734/v5/inc/webrev/

src/hotspot/share/code/codeCache.cpp
     No comments.

src/hotspot/share/oops/method.cpp
     No comments.

src/hotspot/share/runtime/biasedLocking.cpp
     No comments.

src/hotspot/share/runtime/deoptimization.cpp
     No comments.

src/hotspot/share/runtime/deoptimization.hpp
     No comments.

test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java
     No comments.

Thumbs up!

Dan

> Full:
> http://cr.openjdk.java.net/~rehn/8221734/v5/webrev/
>
> 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-runtime-dev mailing list