RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v22]

[Martin Doerr]

On Wed, 10 May 2023 13:33:02 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> GC barriers are used when loading or storing an oop. No GC we currently have (not even the generational ones) use barriers for loading a plain address from an oop. The PPC64 implementation of the BarrierSetAssembler currently has `Unimplemented()` for non-oop types and all GCs are implemented.
>> Maybe it was intended for some future GC or other feature which has not yet reached the official repo.
>
> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189934352