RFR: 8374828: Save load_barrier_on_oop_field_preloaded in aot CodeCache

[Andrew Dinn]

On Thu, 8 Jan 2026 23:18:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Save this address so that the code that uses it in the valhalla repo will have it.  This doesn't fail in main jdk repository.
> See CR for more information.
> Tested with tier1-4.

Aleksey is right that the current code assumes that it can AOT-save and restore i2c/c2i adapters while employing different GCs at each end of the operation because "i2c/c21 adapters are GC-neutral". The truth of that statement relies on the observation that *in both mainline and premain* calls to `resolve_weak_handle` with flags `IN_NATIVE | ON_PHANTOM_OOP_REF` do not generate GC-specific code. The above call occurs when planting c2i code to test whether a target method holder is null/non-null i.e. whether the method is still alive.

So, the fact that you get a missing function in Valhalla confirms that Valhalla is planting a GC-specific barrier for this case. Adding the missing function to the extrs list will indeed allow a reference to the function to be detected/marked at AOT-save and relinked at AOT-restore, making the current AOT save/restore work in Valhalla. However, it will break the assumption that the code is GC-neutral whcih means switching GCs between assembly time and run time will fail.

This addition should indeed raise no error in mainline since the mainline barrier should not plant a reference to the function. I'd recommend that the fix be added only in Valhalla rather than mainline since the current error serves as a canary, indicating that the assumption above has been invalidated.

In the longer term we need to find some way of making code in the AOT cache GC-neutral or give up on being able to switch GCs. I have a patch pending to save/restore all the enumerated stubs (Shared/C1/C2/StubGen) at which point we will definitely lose GC-neutrality unless we implement some barrier patching mechanism; and we will soon be adding nmethods to the cache, exacerbating the problem yet further. We are still discussing options for this in the Leyden dev meetings.

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

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