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

[Daniel D.Daugherty]

On Wed, 15 Jun 2022 22:39:42 GMT, David Holmes <dholmes 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.
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 1003:
> 
>> 1001:     guarantee(current != thread || !JavaThread::cast(thread)->is_gc_barrier_detached(),
>> 1002:               "current cannot touch oops after its GC barrier is detached.");
>> 1003:     oop obj = JavaThread::cast(thread)->threadObj();
> 
> I think the oop-touching-safety check should be done in `threadObj()` itself so that all callers are protected.

The placement in SharedRuntime::get_java_tid() is because that is the failure
mode that this bug is about. My next stress testing experiment will be to put
a similar guarantee() in threadObj(), but I expect there to be more fan-out
from that placement.

This fix is tightly focued on the bug as it is reported because I plan to fix
it in JDK19.

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

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