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