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