RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2]

[David Holmes]

On Thu, 7 Aug 2025 22:26:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Blindly applying acquire/release is not at all the obvious/safe thing to me. I do not understand your reference to `get_handshake_thread()` above - this is not about handshakes. Here we have a very simple situation:
>> - Thread 1: set field; signal target thread
>> - Target thread: receive signal; read field
>> All we need to "transfer" here is the value of "field". acquire/release does not achieve that it only says what happens _if_ you see the new value of field.
>
> Though as I said elsewhere, although the spec does not require it, I would be very surprised if signal raising did not, in practice, "happen-before" signal delivery.

> acquire/release does not achieve that it only says what happens if you see the new value of field

Note I am describing the semantic model for acquire/release in a general sense - as we describe in orderAccess.hpp. An actual implementation may ensure memory operations actually complete before the `release` in a similar way to a `fence` (e.g. X86 `mfence`).

A "fence" may only ensure ordering in its abstract description but that suffices, as the store to the field must happen before any of the stores related to raising the signal, which must happen before the signal can actually be delivered, which happens before we load the field. Hence by transitivity we are guaranteed to see the fields written value, by using the fence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2261646124