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

[Aleksey Shipilev]

On Thu, 7 Aug 2025 12:06:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Might miss updates to what??? We never follow the pointer. 

Following the pointer is not relevant. We can miss updates to the thread pointer. Note that reader needs at least coherence to break out of potential loops like:


while (get_handshake_thread() == nullptr); // burn


Acquire gives that, among other things. Overlooking these properties is easy, and this is why we should be sticking to use atomics anywhere we transfer data between threads.

> We use fence() for "single variable visibility reasons" in a number of places because it is the only thing that actually forces memory synchronization across all threads. 

Well, yes, this part always felt dubious to me. I am restraining myself from going into theoretical argument here, because it would take a lot of time, and would not be helpful for this work.

Since no performance is on the table, we should just do the most obvious/safe thing. I believe it is a proper style to use `Atomic::load_acquire` and `Atomic::release_store_fence`, instead of one-sided `fence`.

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

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