On Wed, 10 May 2023 13:43:41 GMT, Martin Doerr <mdo...@openjdk.org> wrote:
>> You are reasoning about implementation details. By using the provided >> abstraction you and other maintainers (who might be unfamiliar with them) >> would not have to do that. Also the assumptions you make introduce a hidden >> dependency. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189948988
