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

[Anton Artemov]

On Fri, 18 Jul 2025 09:41:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I think it can be that the receiving thread does not manage to report the error, but `safepointTimedOutThread` already got a value, which could confuse the reporting method of `VMError` called on another thread. I think this check is needed, as pointed out by @dholmes-ora .
>
> You lost me here.
> 
> Here we report a SIGILL being received by thread A, sent by thread B. This information is sure.
> 
> Do you mean that thread A was not the intended recipient of the SIGILL?

What I was trying to say is that to rely solely on the non-null value of the "communicative" variable, say `handshakeTimedOutThread` may not be  a good idea, as thread A (SIGILL receiver) may not be able to report the error for some reason. 

In the `handshake::handle_timeout()` code there is a sleep for 3 seconds. Hypothetically if any other thread receives SIGILL for any other reason within this time, while thread A is busy and can't report an error, it (the other thread) wont't be able to report properly as handshakeTimedOutThread already has a value. Therefore a check is the current thread is handshakeTimedOutThread is needed.

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

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