RFR: 8231627: ThreadsListHandleInErrorHandlingTest.java fails in printing all threads

[Daniel D.Daugherty]

On Mon, 4 Jan 2021 16:28:42 GMT, Coleen Phillimore <coleenp at openjdk.org> 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