RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v6]

[Matias Saavedra Silva]

On Thu, 16 Mar 2023 16:11:57 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed aarch64 interpreter mistake
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2335:
> 
>> 2333: 
>> 2334:   __ load_resolved_indy_entry(cache, index);
>> 2335:   __ ldr(method, Address(cache, in_bytes(ResolvedIndyEntry::method_offset())));
> 
> Should this load have acquire semantics?
> Like [here in template interpreter](https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp#L239) and [here for the zero interpreter](https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/hotspot/share/oops/cpCache.inline.hpp#L33)?
> 
> Call stack for zero interpreter is
> 
> ConstantPoolCacheEntry::indices_ord()
> ConstantPoolCacheEntry::bytecode_1()
> ConstantPoolCacheEntry::is_resolved(enum Bytecodes::Code)
> BytecodeInterpreter::run(interpreterState)

Yes, acquire semantics should be used here. Thank you for pointing this out!

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

PR: https://git.openjdk.org/jdk/pull/12778