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

[Daniel D. Daugherty]

On Thu, 16 Jun 2022 07:16:18 GMT, Erik Österlund <eosterlund 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 have also been bitten before by oops being touched at the boundaries of the thread life cycle, so I understand why we would want to be more precise about modelling this in the thread life cycle. The only thing I don't understand with the patch is why there are two alternative state machines now. One that goes through the new state and one that does not go through the new state. There might be a good reason for that, but I would like to understand why that is. And probably have that written in a comment where the two state machines are described.

@fisk's comment from above:
> The only thing I don't understand with the patch is why there are two alternative
> state machines now. One that goes through the new state and one that does not
> go through the new state. There might be a good reason for that, but I would like
> to understand why that is. And probably have that written in a comment where
> the two state machines are described.

There used to be (at least) three alternative state machines. There were two in
JavaThread::exit() and the failing JNI attach is the third. There might be more,
but I haven't found them yet.

[JDK-8286830](https://bugs.openjdk.org/browse/JDK-8286830) ~HandshakeState should not touch oops
changed JavaThread::exit() so we no longer had a path that called current_thread_exiting()
and another path that did not call current_thread_exiting().

Currently we only document the one state machine. I should probably fix that.

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

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