RFR: 8374828: Save load_barrier_on_oop_field_preloaded in aot CodeCache

[Aleksey Shipilev]

On Fri, 9 Jan 2026 08:50:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> That peeking involves no GC action.
>> 
>> Not directly related to this PR, but this caught my eyes. Do you have more information about this somewhere? On the surface this sounds incorrect for ZGC, so I'd like to make sure that there's no bug lurking in there.
>
>> > That peeking involves no GC action.
>> 
>> Not directly related to this PR, but this caught my eyes. Do you have more information about this somewhere? On the surface this sounds incorrect for ZGC, so I'd like to make sure that there's no bug lurking in there.
> 
> IIRC, it is somewhere here in `BarrierSetAssembler::c2i_entry_barrier`:
> 
> 
> void BarrierSetAssembler::c2i_entry_barrier(MacroAssembler* masm) {
> ...
>   __ movptr(tmp1, Address(tmp1, ClassLoaderData::holder_offset()));
>   __ resolve_weak_handle(tmp1, tmp2); // <--- does IN_NATIVE | ON_PHANTOM_OOP_REF inside
>   __ cmpptr(tmp1, 0);
>   __ jcc(Assembler::notEqual, method_live);
> ...
> }
> 
> 
> Again, IIRC, the code that is emitted in this method is part of C2I adapter, so it is stored in AOT cache.

> @shipilev any ideas?

I honestly do not remember what we were thinking :/ I do vaguely recall it was about peeking for nullptrs into phantoms; that is how IIRC we convinced ourselves it was "fine", as there was no GC-specific difference. For current non-peeking resolution in adapters, it does not sound right indeed.

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

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