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

[David Holmes]

On Wed, 6 Aug 2025 08:31:26 GMT, Manuel Hässig <mhaessig at openjdk.org> wrote:

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

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.

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

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