JDK-8288532 : additional review changes for JDK-8286830
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 19
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-06-15
  • Updated: 2022-07-27
  • Resolved: 2022-06-21
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 19 JDK 20
19 b28Fixed 20Fixed
Related Reports
Relates :  
JDK-8286830 - ~HandshakeState should not touch oops
Relates :  
JDK-8288497 - add support for JavaThread::is_oop_safe()
Description
A couple of post-integration review comments for:

    JDK-8286830 ~HandshakeState should not touch oops

should get resolved:


test/hotspot/jtreg/runtime/Thread/StopAtExit.java
        };
        threadCreator.setDaemon(true);
        threadCreator.start();
        test(timeMax);
Member
@dcubed-ojdk dcubed-ojdk 12 days ago

Okay, but now the test is going to execute for twice timeMax which might be
a bit of a surprise... In particular the usage() mesg is now wrong.
Member
@dcubed-ojdk dcubed-ojdk 12 days ago

Also, the @bug line is not updated with this bug ID.
Member Author
@pchilano pchilano 12 days ago

Ok, we could fix this in a new bug.


and 


test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java
        };
        threadCreator.setDaemon(true);
        threadCreator.start();
        test(timeMax);
Member
@dcubed-ojdk dcubed-ojdk 12 days ago

Okay, but now the test is going to execute for twice timeMax which might be
a bit of a surprise... In particular the usage() mesg is now wrong.
Member
@dcubed-ojdk dcubed-ojdk 12 days ago

Also, the @bug line is not updated with this bug ID.
Member Author
@pchilano pchilano 12 days ago

Ok, we could fix this in a new bug.
Comments
Changeset: 31d981e5 Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2022-06-21 16:36:51 +0000 URL: https://git.openjdk.org/jdk19/commit/31d981e5ea0fa4108da5ef94272794a8fed4a363
21-06-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk19/pull/32 Date: 2022-06-16 21:54:56 +0000
17-06-2022
Also going to pick up this sanity check from my recent stress testing: $ git diff diff --git a/src/hotspot/share/runtime/thread.inline.hpp b/src/hotspot/share/runtime/thread.inline.hpp index d01f3015502..8c212ccc80d 100644 --- a/src/hotspot/share/runtime/thread.inline.hpp +++ b/src/hotspot/share/runtime/thread.inline.hpp @@ -147,6 +147,11 @@ class AsyncExceptionHandshake : public AsyncHandshakeClosure { } ~AsyncExceptionHandshake() { + Thread* current = Thread::current(); + if (current->is_Java_thread()) { + guarantee(!JavaThread::cast(current)->is_gc_barrier_detached(), + "JavaThread cannot touch oops after its GC barrier is detached."); + } assert(!_exception.is_empty(), "invariant"); _exception.release(Universe::vm_global()); } The above fix depends on: JDK-8288497 add support for JavaThread::is_gc_barrier_detached()
15-06-2022