RFR: 8374828: Save load_barrier_on_oop_field_preloaded in aot CodeCache

[Stefan Karlsson]

On Mon, 12 Jan 2026 10:31:52 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> 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.

Could you clarify what I'm missing here.

This is the code we are talking about:

void MacroAssembler::resolve_weak_handle(Register result, Register tmp1, Register tmp2) {
  assert_different_registers(result, tmp1, tmp2);
  Label resolved;

  // A null weak handle resolves to null.
  cbz(result, resolved);

  // Only 64 bit platforms support GCs that require a tmp register
  // WeakHandle::resolve is an indirection like jweak.
  access_load_at(T_OBJECT, IN_NATIVE | ON_PHANTOM_OOP_REF,
                 result, Address(result), tmp1, tmp2);
  bind(resolved);
}


which calls:

void MacroAssembler::access_load_at(BasicType type, DecoratorSet decorators,
                                    Register dst, Address src,
                                    Register tmp1, Register tmp2) {
  BarrierSetAssembler *bs = BarrierSet::barrier_set()->barrier_set_assembler();
  decorators = AccessInternal::decorator_fixup(decorators, type);
  bool as_raw = (decorators & AS_RAW) != 0;
  if (as_raw) {
    bs->BarrierSetAssembler::load_at(this, decorators, type, dst, src, tmp1, tmp2);
  } else {
    bs->load_at(this, decorators, type, dst, src, tmp1, tmp2);
  }
}

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.

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

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