On Tue, 7 Mar 2023 13:35:18 GMT, Coleen Phillimore <cole...@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
>
> src/hotspot/cpu/x86/templateTable_x86.cpp line 2801:
>
>> 2799: bool is_invokevirtual,
>> 2800: bool is_invokevfinal,
>> /*unused*/
>> 2801: bool is_invokedynamic
>> /*unused*/) {
>
> I assume you have to keep this parameter for the platform that doesn't still
> have this change (s390)?
That's correct, this method is declared inside the hpp used by all platforms,
so the parameters can't be changed until all the ports are complete.
-------------
PR: https://git.openjdk.org/jdk/pull/12778
