On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva <[email protected]>
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:
>
> Interpreter optimization and comments
src/hotspot/cpu/x86/interp_masm_x86.cpp line 2075:
> 2073: movptr(cache, Address(rbp, frame::interpreter_frame_cache_offset *
> wordSize));
> 2074: movptr(cache, Address(cache,
> in_bytes(ConstantPoolCache::invokedynamic_entries_offset())));
> 2075: if (is_power_of_2(sizeof(ResolvedIndyEntry))) {
This was a good suggestion but I wonder if we should assert ResolvedIndyEntry
is a power of 2 so we know if we change the size and make it go the slower
path? Or is 32 bit not a power of two and we need this?
-------------
PR: https://git.openjdk.org/jdk/pull/12778
