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

[Richard Reingruber]

On Wed, 10 May 2023 13:24:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> As I see it, the access API is an abstraction to be used instead of raw loads. It hides details. See for instance `TemplateTable::getfield_or_static` on x86 where it is also used. PPC lags behind in making use of the access API.
>> With a fancy new GC the oop in nep_reg could be stale, requiring some processing which would be taken care of by using the access API.
>
> 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.

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

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