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

[Manuel Hässig]

On Wed, 6 Aug 2025 11:58:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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.
>
> That is not an accurate characterisation IMO - a memory model defines the consistency of the views of memory by different threads of execution. Any given thread of execution must always have a self-consistent view of memory, and neither the compiler or the CPU is allowed to violate that if code is actually going to be guaranteed to work correctly. If the signal is being handled in the same thread that is setting the flag then you cannot have a memory ordering issue.
> 
> And acquire/release is not the right tool just to establish an ordering: you would generally want a storestore barrier on the writer side, and a loadload barrier on the reader side.

Ah, I see my mistake. 1) I did not think about the C++ memory model, and 2) I thought of the signal handler as a different thread, which made me a bit paranoid. Thank you both for pointing out the mistakes in my thinking.

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

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