> When core reflection was migrated to be implemented by Method Handles, 
> somehow, the method handles are not used for native methods, which are 
> generally linkable by method handles.  This causes significant performance 
> regressions when reflecting native methods, even if their overrides may be 
> non-native methods.  This is evident in `Object.clone` and `Object.hashCode` 
> as shown in the original report.
> 
> I believe the blanket restriction previously placed on the native methods was 
> because of signature polymorphic methods ([JLS 
> 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3),
>  [JVMS 
> 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3))
>  for MethodHandle and VarHandle; method handles do not link to the backing 
> implementation that throws UOE while core reflection is required to do so.  I 
> have narrowed the restrictions to be specifically against these methods.
> 
> Additionally, I cleaned up another check for invalid varargs flag.  Together, 
> I clarified the scenarios where native method accessors are used - all to 
> bypass restrictions of java.lang.invoke.
> 
> Testing: tier 1-5 green

Chen Liang has updated the pull request incrementally with one additional 
commit since the last revision:

  varargs does not matter for effective fix-arity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22169/files
  - new: https://git.openjdk.org/jdk/pull/22169/files/c6d70619..7f77d929

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22169&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22169&range=01-02

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22169.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22169/head:pull/22169

PR: https://git.openjdk.org/jdk/pull/22169

Reply via email to