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

Daniel D.Daugherty dcubed at openjdk.java.net
Tue Jan 5 21:28:56 UTC 2021


On Mon, 4 Jan 2021 18:42:54 GMT, Patricio Chilano Mateo <pchilanomate 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 1130:
> 
>> 1128: 
>> 1129:   if (_to_delete_list != NULL) {
>> 1130:     if (has_Threads_lock) {
> 
> Shouldn't we check for Threads_lock->owned_by_self() instead? (case where thread already owns Threads_lock before calling print_info_on()).

Good idea! That will cover one more "safe" case, but I'll want to rename
the new `has_Threads_lock` to something else.

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

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


More information about the serviceability-dev mailing list