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

Daniel D. Daugherty daniel.daugherty at oracle.com
Mon Jul 8 21:37:32 UTC 2019

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/>

     No comments.

     No comments.

     No comments.

     No comments.

     No comments.

     No comment.

     The copyright year needs to be updated.

     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!


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

More information about the hotspot-runtime-dev mailing list