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

[Hannes Greule]

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

>> 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.

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?

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

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