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

[Chen Liang]

On Tue, 19 Nov 2024 16:35:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 430:
>> 
>>> 428:         // Single parameter of declared type Object[]
>>> 429:         Class<?>[] parameters = reflectionFactory.getExecutableSharedParameterTypes(method);
>>> 430:         return parameters.length == 1 && parameters[0] == Object[].class;
>> 
>> Would it be possible to check for the `PolymorphicSignature` annotation instead?
>
> I think the main problem with annotation is that annotation creation needs to use `java.lang.reflect.Proxy`, which is unavailable until module system is initialized. Extra allocations are costs too, while checks here only reuse existing objects.
> 
> In fact, I don't think Java's core libraries ever check for annotations, and the annotation's support class, `jdk.internal.reflect.ConstantPool`, has always been only loaded but never initialized in a simple hello world program since Java 5.

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.

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

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