JDK-8230594 : Allow direct handshakes without VMThread intervention
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-09-04
  • Updated: 2021-11-09
  • Resolved: 2020-01-22
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 b07Fixed
Related Reports
Cloners :  
JDK-8240918 - [REDO] Allow direct handshakes without VMThread intervention
Relates :  
JDK-8240902 - JDI shared memory connector can use already closed Handles
Relates :  
JDK-8237753 - 32-bit builds are broken after JDK-8230594
Relates :  
JDK-8254264 - Remove redundant cross_modify_fence()
Relates :  
JDK-8234086 - VM operation can be simplified
Relates :  
JDK-8237756 - [BACKOUT]: JDK-8230594: Allow direct handshakes without VMThread intervention
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/e2bc57500c1b User: pchilanomate Date: 2020-01-22 16:52:42 +0000
22-01-2020
Hi Patricio, I see, thanks. My use case goes like this. For JDK-8227745 a JVMTI agent thread A has to reallocate all scalar replaced objects (aka virtual objects) of a java thread J, because they could be part of the result of a subsequent JVMTI operation like GetOwnedMonitorStackDepthInfo(*). Actually it would be fine too, if J would do the reallocation, only the VM thread can't do it. At least I couldn't find an appropriate function that allows the VM thread to allocate from the java heap. So this already resembles direct handshakes, I thought. What I am doing instead is let A suspend J, then reallocate, do the JVMTI operation, and then resume J again. For that I introduced a new suspend flag, and I don't like that too much. Concerning the deadlock issue you mentioned: at least in my case it would be ok to execute the VM_HandshakeAllThreads while the direct handshake is not yet finished. Of course this would add complexity. Anyway, thanks for answering, Richard. (*) L1195 in http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.1/src/hotspot/share/prims/jvmtiEnv.cpp.sdiff.html
22-11-2019
Hi Richard, I think there could be some issues with that. For example, the JavaThread executing the handshake (either handshaker or handshakee) could initiate a vm operation while the VMThread is actually in the middle of a VM_HandshakeAllThreads operation, waiting to handshake the same handshakee. If that were to happen we would deadlock. The current direct handshake will not finish until the vm operation is completed. And the vm operation will not complete since the VMThread is in another vm operation waiting to handshake the previous handshakee. Now, today the real candidate for direct handshakes is biased locking revocation and we don't execute vm operations inside it. All other handshakes, except the one in JVM_CountStackFrames, are VM_HandshakeAllThreads and would still be executed using the VMThread. Which kind of direct handshake are you thinking about that would need that behavior? Is that a new direct handshake? Patricio
21-11-2019
Hi Patricio, would direct handshakes permit nested vm operations? E.g. if java object allocation during the handshake operation trigger gc. This would help in JDK-8227745. Cheers, Richard.
21-11-2019