On Wed, 10 May 2023 13:53:53 GMT, Stefan Karlsson <stef...@openjdk.org> wrote:
>> I just figured it out. It was introduced by >> https://bugs.openjdk.org/browse/JDK-8203172 (on aarch64) which mentions >> Shenandoah and future GCs. However, the Shenandoah comment says >> "non-reference load, no additional barrier is needed" and it doesn't use >> barriers in such a case. So, for the time being, I'll keep the normal load >> (because `access_load_at` is not ready for non-oop types). But I should add >> the `NONZERO` check. > > FWIW, since Shenandoah changed their load barriers we have been cleaning away > the usages of the Access API for loads and stores to primitive values. > There's no such support in the C++ Runtime code. Ok, since this is loading a `long` (which represents an address that points into the code cache) I think we're fine without using the access API then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189996018
