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

[Patricio Chilano]

Hi all,

Could you review this patch that uses thread local handshakes instead of 
safepoints to revoke the biases of locked objects?

Webrev:
http://cr.openjdk.java.net/~pchilanomate/8191890/v01/webrev/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8191890


Today whenever a JavaThread needs to revoke the bias of an object that 
has been biased by another JavaThread (and where the epoch is still 
valid and the prototype header of the class still has the bias pattern) 
it needs to request a safepoint operation. The VMThread inside the 
safepoint walks the stack of the biaser looking for lock records 
associated with the biased object, and converts them to thin locks if 
any are found.
This patch uses thread local handshakes instead, since we actually only 
need to be able to safely walk the stack of the JavaThread that biased 
the object and not other JavaThreads.

Some notes about the patch:

- Thanks to Robbin for initial work on this patch and for advice and 
feedback!
- We still execute bulk rebias and bulk revoke operations inside 
safepoints, since in those cases all the JavaThread's stacks need to be 
walked to potentially update lock records.
- The method revoke_bias() was renamed to single_revoke_at_safepoint(). 
This method is still kept because there are places where we check 
whether we are already at safepoint when trying to revoke. In those 
cases, if we are already at a safepoint we simply end up calling this 
method.
- Handshakes are executed as VMOperations so the VMThread is still 
involved in the revocation. This means we cannot have different 
revocations being executed in parallel (same as with safepoints). 
Ideally we would like to execute thread local handshakes without needing 
for the VMThread to participate. However, now other JavaThreads that do 
not participate in the revocation are allow to continue making progress.

Run several benchmarks and mostly performance seems unaffected. Measured 
the average time it takes for revoking bias with a handshake and with a 
safepoint and numbers are pretty similar varying between benchmarks. 
Some numbers are shown below:

specjbb2015
                      Handshakes      Safepoints
Linux                        4ms            4.6ms
Windows                 11ms             19ms

startup benchmarks
                     Handshakes      Safepoints
Linux                    159us             248us
Windows               150us             111us

Overall the variation is not enough to show significant difference in 
performance, considering also that revocations of a valid biaser are 
usually a fraction of the overall running time of a benchmark (specially 
jbb2015). In any case using handshakes allows other JavaThreads to make 
progress during that time, minimizing STW operations.

In terms of testing, the patch passed several runs of tiers1-6 in mach5 
on Windows, Linux, MacOS and Solaris.

Thanks!

Patricio