RFR: 8308094: Add a compilation timeout flag to catch long running compilations [v2]

[Dean Long]

On Tue, 5 Aug 2025 08:52:20 GMT, Manuel Hässig <mhaessig at openjdk.org> wrote:

>> src/hotspot/share/compiler/compilerThread.cpp line 97:
>> 
>>> 95:     switch (signo) {
>>> 96:       case TIMEOUT_SIGNAL: {
>>> 97:         assert(!Atomic::load_acquire(&_timeout_armed), "compile task timed out");
>> 
>> Why do we need acquire?  Only the current thread is ever going to be looking at this value, right?
>
> The compiler thread setting and unsetting the flag and the signal handler reading the flag are racing each other as soon as the timer is set, since signals are preemptive. This prevents a few false positive timeouts on architectures with weak memory models, but does not have any effect on x86 for example.

The signal is delivered to the same compiler thread, so I don't think acquire and release help here.  There shouldn't be a weak memory model issue between a thread and it's signal handler on the same thread.  Can you explain the sequence of events that could cause a false positive?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26023#discussion_r2255395595