JDK-8239084 : Allow handshake operations inside safepoints
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-02-14
  • Updated: 2023-01-06
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8238585 - JvmtiEventControllerPrivate::enter_interp_only_mode() should not make compiled methods on stack not_entrant
Relates :  
JDK-8252906 - Investigate nested safepoint/handshaking inside a handshake
Description
As handshakes get more uses in hotspot the scenarios where we could execute one are expanding. In particular JDK-8238585 identified the need to execute one inside a safepoint. We can address this directly in the handshake code instead of having the caller work around it.
Comments
The original fix which was to move the if(SafepointSynchronize::is_at_safepoint()) inside Handshake::execute(): void Handshake::execute(HandshakeClosure* thread_cl) { if (SafepointSynchronize::is_at_safepoint()) { Threads::java_threads_do(thread_cl); return; } .... bool Handshake::execute(HandshakeClosure* thread_cl, JavaThread* target) { if (SafepointSynchronize::is_at_safepoint()) { thread_cl->do_thread(target); return true; } ... } needs to be re-thinked. There could be calls to Handshake::execute() at a safepoint by NonJavathreads that should still be handled as a normal operation by the VMThread, like the handshake call in ZMark::flush(). Adding "&& Thread::current()->is_VM_thread()" to the if statement will solve that issue. But current pattern in deoptimization code cannot be removed unless we know only the VMThread executes that path at a safepoint (which seems to be the case), so the code remains equivalent.
18-02-2020