On Wed, 10 May 2023 13:24:55 GMT, Martin Doerr <mdo...@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
