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

[David Holmes]

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

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

@dcubed-ojdk I must admit I'm also not a fan of adding this very specialized interim state into the thread termination states. I would have expected the barrier code itself to be able to detect when `on_thread_detach` had been called, instead of the `JavaThread` having to track that for itself.

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

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