RFR: 8288497: add support for JavaThread::is_gc_barrier_detached()

[Daniel D.Daugherty]

On Wed, 15 Jun 2022 18:52:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows
>> us to add checks to detect failures like:
>> 
>>     JDK-8288139 JavaThread touches oop after GC barrier is detached
>>     https://bugs.openjdk.org/browse/JDK-8288139
>> 
>> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8].
>> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running.
>
> I think I would just use the _thread_terminated state rather than introducing a new _thread_gc_barrier_detached state just to detect failures. So the only extra things covered by _thread_gc_barrier_detached and not by _thread_terminated would be ThreadService::remove_thread() which just updates some counters, and ThreadsSMRSupport::remove_thread() which we overlooked before but now by inspection I don't see any other place where we touch oops there.

@pchilano - Thanks for the review!

Since we've been having issues with oop usage after the GC barrier is detached
in several bugs, I was going for the more precise control of adding the new
TerminatedTypes value. There is quite a bit of code from:

old L3600: `BarrierSet::barrier_set()->on_thread_detach(p);`

to

old L3623: `p->set_terminated(JavaThread::_thread_terminated);` 

so rather than have to reason about the code over and over again,
I would rather do these sanity checks with targeted code. To paraphrase
@robehn: Why do with code inspection what you can do with code?

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

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