RFR: 8288139: JavaThread touches oop after GC barrier is detached
Daniel D.Daugherty
dcubed at openjdk.java.net
Wed Jun 15 16:45:53 UTC 2022
Update SharedRuntime::get_java_tid() to verify that the calling thread is safely
accessing its own threadObj(). This check uses the new is_gc_barrier_detached()
function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached().
The above check was used to reproduce the failure mode without Shenandoah
and the remainder of the fix relocates the offending code from
ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of
removed the 'tid' entry from the ThreadIdTable is still done under the
protection of the Threads_lock.
This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8].
There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running.
-------------
Depends on: https://git.openjdk.org/jdk19/pull/20
Commit messages:
- 8288139: JavaThread touches oop after GC barrier is detached
Changes: https://git.openjdk.org/jdk19/pull/21/files
Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=21&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8288139
Stats: 22 lines in 4 files changed: 9 ins; 6 del; 7 mod
Patch: https://git.openjdk.org/jdk19/pull/21.diff
Fetch: git fetch https://git.openjdk.org/jdk19 pull/21/head:pull/21
PR: https://git.openjdk.org/jdk19/pull/21
More information about the hotspot-runtime-dev
mailing list