RFR: 8288497: add support for JavaThread::is_gc_barrier_detached()
Daniel D. Daugherty
dcubed at openjdk.org
Thu Jun 16 16:17:00 UTC 2022
On Thu, 16 Jun 2022 15:55:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
>> src/hotspot/share/runtime/thread.cpp line 3601:
>>
>>> 3599: // requiring the GC state to be alive.
>>> 3600: BarrierSet::barrier_set()->on_thread_detach(p);
>>> 3601: if (p->is_exiting()) {
>>
>> I don't understand why this needs to be conditional?
>
> The "normal" transitions for a JavaThread's _terminated field are:
>
> _not_terminated => _thread_exiting => _thread_gc_barrier_detached => _thread_terminated
>
> The transitions for a JavaThread that failed to attach are:
>
> _not_terminated => _thread_terminated
>
> because that JavaThread does not calls JavaThread::exit(). If we try to take
> the attach failing JavaThread thru _thread_gc_barrier_detached, then some
> of the counter code will be unhappy and we'll see assertion failures.
I just dug up my testing notes:
gc/g1/ihop/TestIHOPStatic.java fails in fastdebug and slowdebug:
# Internal Error (/System/Volumes/Data/work/shared/bug_hunt/8288139_for_jdk19.git/open/src/hotspot/share/services/threadService.cpp:177), pid=3359, tid=5891
# assert(_live_threads_count->get_value() > count) failed: thread count mismatch 6 : 6
So the purpose of the condition is so that an attach failing JavaThread has the
same transitions that it always had.
-------------
PR: https://git.openjdk.org/jdk19/pull/20
More information about the hotspot-runtime-dev
mailing list