RFR: 8301997: Move method resolution information out of the cpCache [v10]

[Matias Saavedra Silva]

On Thu, 9 Nov 2023 22:48:28 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for methods, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure previously held information for fields, methods, and invokedynamic calls which were all encoded into f1 and f2. Currently this structure only handles method entries, but it remains obtuse and inconsistent with recent changes. 
>> 
>> This enhancement introduces a new data structure that stores the necessary resolution data in an intuitive an extensible manner. These resolved entries are stored in an array inside the constant pool cache in a very similar manner to invokedynamic entries in JDK-8301995.
>> 
>> Instances of ConstantPoolCache entry related to field resolution have been replaced with the new ResolvedMethodEntry, and ConstantPoolCacheEntry has been removed entirely. The class ResolvedMethodEntry holds resolution information for all types of invoke calls besides invokedynamic, and thus has fields that may be unused depending on the invoke code. 
>> 
>> To streamline the review, please consider these major areas that have been changed:
>> 1. ResolvedMethodEntry class
>> 2. Rewriter for initialization of the structure
>> 3. cpCache for resolution
>> 4. InterpreterRuntime, linkResolver, and templateTable
>> 5. JVMCI
>> 6. SA
>> 
>> Verified with tier 1-9 tests.
>> 
>> This change supports the following platforms: x86, aarch64, RISCV, PPC
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - PPC port
>  - Improved load_resolved_method_entry_handle on x86 and aarch64

> I have a version which works for PPC64: [TheRealMDoerr at 6bff392](https://github.com/TheRealMDoerr/jdk/commit/6bff39224e3129a898711a392b64c38b331d79a2)
> 
> Note that I have implemented a few things slightly differently:
> 
>     * `TemplateTable::load_resolved_method_entry_handle`: I'm loading the method at the end which avoids pushing and popping it on the expression stack which is not so nice IMHO. This works because I'm using a non-volatile register (asserted) for `cache` which is still valid after the C-call in `resolve_oop_handle`.
> 
>     * `TemplateTable::load_resolved_method_entry_interface` and `TemplateTable::load_resolved_method_entry_virtual`: I'm not putting values in registers depending on the flags because it doesn't fit nicely into the PPC64 design. I found myself scratching my head and thinking about what is in the register in which case. Instead of that, I'm loading the fields where they are needed which leads to a much cleaner design. I always know what is in which register this way.
> 
> 
> Please take a look and take these differences into consideration for other platforms. Thanks!

Thank you for the port! I liked your recommendation with regards to invokehandle and added that change to x86 and aarch64 as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15455#issuecomment-1804803551