RFR: 8288139: JavaThread touches oop after GC barrier is detached

[Robbin Ehn]

On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> 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.

Hi

After we have done:

if (JvmtiEnv::environments_might_exist()) {
    JvmtiExport::cleanup_thread(this);
}

I don't think there is any valid use case of ThreadIdTable.
So can't we just remove the thread from the table here instead:

I.e.

if (JvmtiEnv::environments_might_exist()) {
    JvmtiExport::cleanup_thread(this);
}

if (ThreadIdTable::is_initialized()) {
    jlong tid = SharedRuntime::get_java_tid(thread);
    ThreadIdTable::remove_thread(tid);
}


?

-------------

PR: https://git.openjdk.org/jdk19/pull/21