On Tue, 7 Mar 2023 14:00:19 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/hotspot/share/oops/cpCache.cpp line 727:
>
>> 725: set_reference_map(nullptr);
>> 726: #if INCLUDE_CDS
>> 727: if (_initial_entries != nullptr) {
>
> @iklam with moving invokedynamic entries out, do you still need to save
> initialized entries ? Does invokehandle need this? (Should have separate RFE
> if more cleanup is possible)
This along with the previous comment about `_invokedynamic_references_map`
would probably be better suited for their own RFE. I think the scope of this PR
should be limited to the indy structure and its implementation, so any changes
related to invokehandle can be traced more easily.
-------------
PR: https://git.openjdk.org/jdk/pull/12778
