On Tue, 19 Nov 2024 16:45:47 GMT, Hannes Greule <hgre...@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
