RFR: 8364819: Post-integration cleanups for JDK-8359820 [v2]
David Holmes
dholmes at openjdk.org
Thu Aug 7 12:09:16 UTC 2025
On Thu, 7 Aug 2025 10:49:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> @shipilev The memory consistency is about seeing the writes to these fields in the thread that is signalled. acquire/release has no meaning in this context. I would not add acquire/release just in case someone in the future actually tried to follow those pointers - they are only for identifying purposes. If you are worried about that then lets go back to changing them to a value (intptr_t) so it will never be an issue.
>
> It always feels dubious to me to add fences for the single-variable "visibility" reasons. The fences order things relative to other things, not just "flush" or "make this single variable visible". But that's a theoretical quibble. A more pressing problem is reading the thread marker without any acquire/relaxed semantics; _that_ might miss updates as well.
>
> Given how messy C++ memory model is, and how data races are UB-scary there, I think we should strive to do `Atomic`-s as the matter of course for anything that transfers data between threads. Adjusting `Atomic::release_store` -> `Atomic::release_store_fence` would have satisfied both flavors of concurrency paranoia we are having, I think: it is equivalent to having a fence after the store, and it clearly makes Atomic release->acquire chain as well :)
> that might miss updates as well.
Might miss updates to what??? We never follow the pointer. The signalling thread doesn't doesn't do anything that the signallee has to look at, the signallee just gets the signal, checks if it was the timeout target and aborts.
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. acquire/release just says "if you see this then you must see that", it doesn't do anything to help you "see this" in the first place.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26656#discussion_r2260118952
More information about the hotspot-dev
mailing list