JDK-8264663 : Update test SuspendWithCurrentThread.java to verify that suspend doesn't exit until resumed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-04-02
  • Updated: 2021-05-04
  • Resolved: 2021-04-26
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 17
17 b20Fixed
Related Reports
Relates :  
JDK-8257831 - Suspend with handshakes
Description
Test test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/SuspendWithCurrentThread.java

tries to suspend the thread list which includes the current thread. However, it suspends and resumes list under the same agent_monitor lock.

The test really should hang. See fix in loom:
https://github.com/openjdk/loom/commit/c088b36d0e94fe7527239f716754d395675d3e1e

The test should be updated in a similar way. Also, it should check that resume is actually called before test continue execution after suspend.
Comments
Changeset: b5c63513 Author: Leonid Mesnik <lmesnik@openjdk.org> Date: 2021-04-26 19:48:57 +0000 URL: https://git.openjdk.java.net/jdk/commit/b5c63513
26-04-2021
The test fix in JDK-8257831 just removes deadlock but doesn't verify that SuspendWithCurrentThread doesn't exit. So this issue is still actual. Currently, SuspendWithCurrentThread doesn't block the current thread. The thread is suspended only during leaving VM. So some native code might be still executed between these two points. It still should be tested.
05-04-2021
[~rehn] also discovered this and has included a fix as part of JDK-8257831
04-04-2021