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

[Martin Doerr]

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

>>> It does the same but with a more complicated API.
>> 
>> AFAIK It depends on the GC that's being used. `access_load_at` will make sure the right GC barriers are inserted (mostly for concurrent GCs).
>
> 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.

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

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