On Mon, 4 Jan 2021 16:28:42 GMT, Coleen Phillimore <[email protected]> wrote:
>> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the
>> likelihood of crashes during error reporting. Uses Threads_lock->try_lock()
>> for safety and restricts some reporting to when the Threads_lock has been
>> acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make
>> the current ThreadsList safe for reporting (depends on JDK-8258284). Also
>> detects when the system ThreadsList (_java_thread_list) has changed and
>> will warn that some of the reported info may now be stale.
>>
>> Two existing tests have been updated to reflect the use of a
>> ThreadsListHandle
>> in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no
>> regressions.
>
> src/hotspot/share/runtime/threadSMR.cpp line 1161:
>
>> 1159: return;
>> 1160: }
>> 1161: st->print_cr("_java_thread_list_alloc_cnt=" UINT64_FORMAT ", "
>
> Are these statistics stable if you don't have the Threads_lock? Seems like a
> good place to return unconditionally to me, but it's up to you whether this
> is wrong and it matters. It doesn't follow any pointers so doesn't look like
> it'll crash.
No the statistics starting on L1161 are not stable if we don't
have the Threads_lock. That's why we detect a change in the
_java_thread_list on L1194 and print a message:
if (_java_thread_list != saved_threads_list) {
st->print_cr("The _java_thread_list has changed from " INTPTR_FORMAT
" to " INTPTR_FORMAT
" so some of the above information may be stale.",
p2i(saved_threads_list), p2i(_java_thread_list));
}
-------------
PR: https://git.openjdk.java.net/jdk/pull/1891
