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
I have a couple of very minor comments. This change is great. Thank you!
src/hotspot/cpu/x86/templateTable_x86.cpp line 2798:
> 2796: bool is_invokevirtual,
> 2797: bool is_invokevfinal,
> /*unused*/
> 2798: bool is_invokedynamic
> /*unused*/) {
Can you remove the parameter since the s390 port is here?
src/hotspot/share/oops/resolvedIndyEntry.hpp line 112:
> 110: set_flags(has_appendix);
> 111: // Set the method last since it is read lock free.
> 112: // Resolution is indicated by whether or not he method is set.
typo: he -> the
-------------
Marked as reviewed by coleenp (Reviewer).
PR: https://git.openjdk.org/jdk/pull/12778
