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

Serguei Spitsyn sspitsyn at openjdk.java.net
Tue Jan 5 09:46:56 UTC 2021


On Mon, 4 Jan 2021 18:43:40 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 1148:
> 
>> 1146:     }
>> 1147:   }
>> 1148:   if (!EnableThreadSMRStatistics) {
> 
> You could switch to "if(EnableThreadSMRStatistics)" instead and put this code at the end to avoid repetition. Also I think the comparison with _java_thread_list could be done unconditionally at the end since it's already racy anyways (even if the info was printed with the Threads_lock held it could have changed right after it's released and before returning).

I like the refactoring suggestion from Patricio above to switch to "if(EnableThreadSMRStatistics)". The code will be a little more elegant.

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

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


More information about the serviceability-dev mailing list