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

[Manuel Hässig]

On Tue, 5 Aug 2025 21:33:52 GMT, Dean Long <dlong at openjdk.org> wrote:

>> 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?

As far as I understand weak memory models, the concept of threads, which the CPU does not know of, is irrelevant. The CPU is merely free to reorder a subset of memory operations. The reason I added the acquire/release semantics is to prevent the reordering of a write to `_timeout_armed` that happened before a read from the same in the signal handler. This is only relevant when a compilation is done and the timeout is disarmed just before the timer fires. 

Granted, this is an edge case that does not create a huge amount of false positives. Also, it might be entirely unnecessary due to the OS doing some work to call the signal handler in-between the write and the read of the value. It is merely conservative programming, so I am fine with dropping the barriers.

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

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