RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads

[Coleen Phillimore]

On Thu, 24 Dec 2020 17:33:21 GMT, Daniel D. Daugherty <dcubed 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.

Looks good.  One comment.  Also, ha ha, Harold caught me today: you need to update the copyrights!

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.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1891