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