RFR: 8359820: Improve handshake/safepoint timeout diagnostic messages [v3]

Thomas Stuefe stuefe at openjdk.org
Fri Jul 18 08:10:59 UTC 2025


On Fri, 18 Jul 2025 07:41:44 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> The problem in the issue description is not a problem by itself, the behavior is not unexpected, but it is somewhat difficult to find out what caused SIGILL to be fired.
>> 
>> We propagate this information from `handshake::handle_timeout()` to `VMError::report()` with a help of a global variable.  The same mechanism is used to address a similar issue in the safepoint timeout handler. 
>> 
>> Tested in tiers 1-3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359820: Addressed reviewer's comments

src/hotspot/share/utilities/globalDefinitions.hpp line 1351:

> 1349: // Indicate VMError::report() that SIGILL came from safepoint timeout handler, report which thread timed out
> 1350: extern intptr_t safepointTimedOutThread;
> 1351: 

Do we really need this in globalDefinitions? This seems to be a mechanism highly specific to error handling and safe points.

src/hotspot/share/utilities/vmError.cpp line 827:

> 825:         } else {
> 826:           st->print(" (sent by kill)");
> 827:         }

I don't understand.

Should not the receiving thread be the timeouted thread? So the one that is executing right now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2215312969
PR Review Comment: https://git.openjdk.org/jdk/pull/26309#discussion_r2215320610


More information about the hotspot-runtime-dev mailing list