JDK-8240918 : [REDO] Allow direct handshakes without VMThread intervention
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2020-03-12
  • Updated: 2020-07-28
  • Resolved: 2020-04-08
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 15
15 b18Fixed
Related Reports
Blocks :  
JDK-8240902 - JDI shared memory connector can use already closed Handles
Blocks :  
JDK-8201641 - JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes
Cloners :  
JDK-8230594 - Allow direct handshakes without VMThread intervention
Relates :  
JDK-8250610 - SafepointMechanism::disarm_if_needed() is declared but not used.
Relates :  
JDK-8242484 - Rework thread deletion during VM termination
Relates :  
JDK-8238585 - JvmtiEventControllerPrivate::enter_interp_only_mode() should not make compiled methods on stack not_entrant
Description
Today all handshakes execute as a VM_Operation requiring the VMThread to mediate between the handshaker and handshakee. We can try to have direct handshakes without requiring the help of the VMThread, at least as a possibility for handshakes, not necessarily mandatory.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/e2faa00e8d67 User: pchilanomate Date: 2020-04-08 18:33:54 +0000
08-04-2020
Although the reason behind the backout of 8230594 was 8240902 this redo will address an issue not identified in the original patch. The issue could be seen if a target JavaThread called Thread::destroy_vm() while there were handshakers waiting in the handshake_turn_sem. This can happen for example if the target is the JavaMain thread, which already returned and is now calling LEAVE(). The destroy_vm() method will eventually call a safepoint which can progress while there are JavaThreads blocked safepoint safe in that semaphore. The thread executing destroy_vm() assumes at the end of the method that nobody could be holding a reference to itself so it calls delete thread. That in turn calls the ~HandshakeState destructor which calls the ~Semaphore destructor, destroying the _handshake_turn_sem while there are other JavaThreads waiting on it.
01-04-2020