On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva <matsa...@openjdk.org> wrote:
>> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >> methods, and invokedynamics and each of its fields can hold different types >> of values depending on the entry. >> >> This enhancement proposes a new structure to exclusively contain >> invokedynamic information in a manner that is easy to interpret and easy to >> extend. Resolved invokedynamic entries will be stored in an array in the >> constant pool cache and the operand of the invokedynamic bytecode will be >> rewritten to be the index into this array. >> >> Any areas that previously accessed invokedynamic data from >> ConstantPoolCacheEntry will be replaced with accesses to this new array and >> structure. Verified with tier1-9 tests. >> >> The PPC was provided by @reinrich and the RISCV port was provided by >> @DingliZhang and @zifeihan. >> >> This change supports the following platforms: x86, aarch64, PPC, and RISCV > > Matias Saavedra Silva has updated the pull request incrementally with one > additional commit since the last revision: > > Improved comment for load-acquire aarch64 src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2294: > 2292: > 2293: __ load_resolved_indy_entry(cache, index); > 2294: __ ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), > cache); @reinrich this load needs acquire semantics. src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2308: > 2306: // Update registers with resolved info > 2307: __ load_resolved_indy_entry(cache, index); > 2308: __ ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), > cache); @reinrich same for this one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1146343430 PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1146343487
