RFR: 8267585: JavaThread::set_thread_state generally needs release semantics

[David Holmes]

On Wed, 21 Jul 2021 09:17:11 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I don't agree with the assertion we didn't have clean platform independent code when PPC64 was introduced as justification here. We already had closed ports of ARM and PPC at that time and we had done a lot (ever since IA64 work years earlier) to make the shared code platform (and TSO) agnostic. Sure it wasn't/isn't perfect but I don't think you can use that as a justification here. I couldn't find anything that explained why PPC64 took the path it did (nor the discussion that forced the acquire/release to be restricted to PPC64 due to performance concerns on other platforms). The Aarch64 port at least tries to justify it, but I'd argue always using acquire/release semantics with thread-state was a sledgehammer approach to avoid actually identifying which interactions actually need what kind of memory barriers.
>
> I'm not happy with the sledgehammer, either, but better using a sledgehammer than having possibly incorrect code or an unstable VM IMHO.
> No problems reported on some platforms doesn't mean that the code is correct. Do we know that not using release/acquire is correct for any platform? The aarch64 issue doesn't sound like that.
> IA64 is not affected because volatile accesses always use release/acquire semantics. I believe that arm32 uses that, too. So, we already rely on release/acquire semantics. Shouldn't that better be explicit?

The need for acquire/release semantics needs to be established for pairs of accesses. Simply using them "just in case" is not something I support and I certainly discourage it because it says "we don't understand our code so we're just throwing barriers in just in case".

That said there seems no interest in this change so I will just close it out.

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/4825