RFR 8191890: Biased locking still uses the inferior stop the world safepoint for revocation

[Daniel D. Daugherty]

On 7/7/19 3:09 PM, Patricio Chilano wrote:
> Hi all,
>
> Below is the webrev for v05. This is just v04 on top of a new baseline 
> that includes the backout of 8221734 and other changes made to 
> biasedLocking code by 8225702 and 8225344.
> The only difference between v05 and v04 is the use of 
> SafepointSynchronize::safepoint_id() instead of 
> SafepointSynchronize::safepoint_counter() introduced by 8225702, and 
> not having to remove method 
> BiasedLocking::revoke_own_locks_in_handshake() and to edit method 
> Deoptimization::revoke_using_handshake() which were actually removed 
> by the backout of 8221734.
>
> Full Webrev:
> http://cr.openjdk.java.net/~pchilanomate/8191890/v05/webrev/ 
> <http://cr.openjdk.java.net/%7Epchilanomate/8191890/v05/webrev/>

src/hotspot/share/interpreter/interpreterRuntime.cpp
     No comments.

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

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

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

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

src/hotspot/share/runtime/vmOperations.hpp
     No comment.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMOps.java
     The copyright year needs to be updated.

test/jdk/jdk/jfr/event/runtime/TestBiasedLockRevocationEvents.java
     No comments.

I did the first pass review using:

     $ jfilemerge -r open.8191890.v4.patch open.8191890.v5.patch

and nothing jumped out at me. I did a quick review of the
v5 webrev and the only thing I noticed was the copyright
year mentioned above.

I have to repeated a comment from the v01 code review:

 > Outstanding job on a very arcane and complicated part of the system.

Thanks for sticking with this fix!

Dan


>
> Tested with tiers1-7. Running another round now.
>
> Thanks!
> Patricio