On Tue, 7 Mar 2023 14:10:33 GMT, Coleen Phillimore <[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
>
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java
> line 935:
>
>> 933: /*if (isInvokedynamicIndex(cpi)) {
>> 934: compilerToVM().resolveInvokeDynamicInPool(this,
>> cpi);
>> 935: }*/
>
> Is there something to fix here?
That's a vestige of old code that I don't believe is necessary anymore.
Invokedynamic is resolved further up so that can be removed. I think it makes
sense to leave the invokedynamic case for completeness, but it will be left
blank.
-------------
PR: https://git.openjdk.org/jdk/pull/12778
