RFR: 8343377: Performance regression in reflective invocation of native methods

[Chen Liang]

On Tue, 19 Nov 2024 16:45:47 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> In fact, another solution I have contemplated is to update `JavaLangInvokeAccess` implementations. 4 methods in it, `unreflectConstructor`, `unreflectField`, `findVirtual`, and `findStatic`, are exclusively used by core reflection.
>> 
>> That solution proposes to bypass `findVirtualForMH`/`findVirtualForVH` and bypass `setVarargs(MemberName)` in `getDirectMethodCommon`/`getDirectConstructorCommon` in these internal hooks.
>> 
>> But I think this may be too invasive and unfriendly to backports (also note: backport to 21 isn't clean, there is a small conflict in doc comments), and using native instead of MH for these 2 corner cases shouldn't be too big of a performance concern.
>
> Okay, in that case it's probably fine - I assume there's also no easy way to ensure in a test that all signature polymorphic methods are covered by these checks?

These checks are 1-1 to the JVMS 2.9.3/JLS 15.12.3, where definitions of signature polymorphic methods reside.

Actually, since you've asked, I checked the usage of `PolymorphicSignature` - it's not used by javac at all! The only usages I can find is in JVMCI tests. And I don't find any test that verify the set of all `PolymorphicSignature` annotated methods is the set of all signature polymorphic methods. (A similar test exists for `CallerSensitive`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22169#discussion_r1848752806