RFR: 8320418: PPC64: invokevfinal_helper duplicates code to handle ResolvedMethodEntry

[Martin Doerr]

On Mon, 20 Nov 2023 17:26:15 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> `TemplateTable::invokevfinal_helper` should use `TemplateTable::prepare_invoke`. `TemplateInterpreter::invoke_return_entry_table_for` needs to support `_fast_invokevfinal` bytecode for that which is only used by PPC64. (It is probably still beneficial for AIX which doesn't support CDS.)
>> In addition, I've cleaned up some inaccurate comments.
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3536:
> 
>> 3534:            Rrecv       = Rscratch2;
>> 3535:   __ ld(Rnum_params, in_bytes(Method::const_offset()), Rmethod);
>> 3536:   __ lhz(Rnum_params /* number of params */, in_bytes(ConstMethod::size_of_parameters_offset()), Rnum_params);
> 
> [`ConstMethod::_size_of_parameters`](https://github.com/openjdk/jdk/blob/0712b22a3ae7075304e5925365429e1d85bd173c/src/hotspot/share/oops/constMethod.hpp#L208) is the size of the parameter block in words. `prepare_invoke` uses `ResolvedMethodEntry::_number_of_parameters` which is `Number of arguments for method`. I'd expect the location of the receiver to depend on the size of the parameters and not their number. How does this work?

One is a copy of the other. See usages of `method_entry->fill_in` in src/hotspot/share/oops/cpCache.cpp. E.g.
`method_entry->fill_in((u1)as_TosState(method->result_type()), (u2)method()->size_of_parameters());`
Scaling happens in `load_receiver`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16741#discussion_r1399675411