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

[Aleksey Shipilev]

On Thu, 7 Aug 2025 23:37:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

As I said before, getting too deep into theory and how this case might be special is counter-productive here.

Honestly, I do _not_ understand the aversion to the idea that a field that is accessed by several threads should be nominally wrapped with `Atomic`. (Also note that some fields in `VMError` already do this.) Whatever the current situation is, that might allow for a low-level naked fence, the situation can change. I strongly believe we should be erring on the side of caution and future-proofness, unless there are other concerns on the table, like performance. There is no other concerns here, AFAICS. If you want a `fence` after the store for whatever reason, that's fine, there is `Atomic::release_store_fence` that gives it.

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

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