JDK-8191890 : Biased locking still uses the inferior stop the world safepoint for revocation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-11-27
  • Updated: 2019-08-15
  • Resolved: 2019-07-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14
14 b05Fixed
Related Reports
Relates :  
JDK-8228758 - assert(_no_handle_mark_nesting == 0) failed: allocating handle inside NoHandleMark
Relates :  
JDK-8191785 - revoke_bias() needs a new assertion
Relates :  
JDK-8227528 - TestAbortVMOnSafepointTimeout.java failed due to "RuntimeException: 'Safepoint sync time longer than' missing from stdout/stderr"
Description
A single thread thread-local handshake would perform much better.
Comments
JDK-8228758 has demonstrated that there is a general problem with using handshakes to execute code previously only executed by the VMThread at a safepoint. We can get into situations where we have unexpected "nested" code sequences, and perhaps even unexpected reentrancy in the general case.
30-07-2019