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

[Albert Mingkun Yang]

On Tue, 12 Aug 2025 09:16:21 GMT, Anton Artemov <duke at openjdk.org> wrote:

> I think we have 2 orthogonal problems here:

I was aware of only the first one. Thank you for the clarification.

Conventionally, the `Atomic::X` is used to access  `volatile` vars, so the getters should be updated as well.

> I came to conclusion that the 1st issue is not an issue, as signal firing and receiving is very heavy compared by a simple store to a variable.

Maybe such "heavy" operation contains enough instructions that CPU doesn't/couldn't reorder the important read... Just to be explicit, the following is the problematic scenario I had in mind, and I assume it's the same one Aleksey talked about.

<details>

<summary>litmus source</summary>


C signal

{
[x] = 0;
[y] = 0;
}

P0 (atomic_int* x, atomic_int* y) {
  atomic_store_explicit(x, 1, memory_order_relaxed);

  atomic_thread_fence(memory_order_seq_cst);

  atomic_store_explicit(y, 1, memory_order_seq_cst);
}

P1 (atomic_int* x, atomic_int* y) {
  r0 = atomic_load_explicit(y, memory_order_relaxed);
  // required to prevent loading-x from floating up
  atomic_thread_fence(memory_order_acquire);
  if (r0 == 1) {
    r1 = atomic_load_explicit(x, memory_order_relaxed);
  }
}

exists
(  true
/\ 1:r0 == 1
/\ 1:r1 == 0
)

</details>

`herd7 -c11 -cat rc11.cat signal.litmus` shows that the `acquire`-fence on the reader side is necessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/26656#issuecomment-3178683893