RFR: 8374828: Save load_barrier_on_oop_field_preloaded in aot CodeCache

[Andrew Dinn]

On Mon, 12 Jan 2026 12:30:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> and the bs->load_at call is a virtual call that could call into ZBarrierSetAssembler::load_at.
> 
> It is still unclear to my in what way this is not GC-specific. Sorry if I'm missing something obvious here and thereby derailing this PR.

Yes, I understand that there is a virtual call that enters a GC-specific barrier implementation. However, the issue is not whether GC-specific code is executed at generate time but whether the generated code that results differs from one GC to the next.

When we added save and restore of i2c/c2i stubs to the AOT cache all the GCs for which AOT caching was then an option generated the same code if flags was passed as `IN_NATIVE | ON_PHANTOM_OOP_REF` i.e. a plain load (use of ZGC when generating or consuming an AOT cache was not an option at that point). That meant that an i2c/c2i adapter code generated in the assembly run and saved to the cache was suitable for use in a production run whatevre the GC setting.

Are you saying that for this specific flag combination the code generated by `ZBarrierSetAssembler::load_at` as currently implemented in *mainline* is more than just a simple load? Clearly, that is true in the Valhalla tree where the error reported by @coleenp indicates the barrier is generating code that references `ZBarrierSetRuntime::load_barrier_on_oop_field_preloaded_addr` etc. However, she suggested this was not an issue in mainline. Does the mainline code differ in some other way?

If so then this would mean that the assumption made above has been weakened and that an AOT cache generated with ZGC enabled can only be used in a production run using ZGC and vice versa.

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

PR Comment: https://git.openjdk.org/jdk/pull/29129#issuecomment-3738724324