RFR: 6983726: remove Proxy from MethodHandleProxies.asInterfaceInstance SAM conversion [v7]
Mandy Chung
mchung at openjdk.org
Thu Apr 6 18:12:25 UTC 2023
On Thu, 6 Apr 2023 17:18:22 GMT, Chen Liang <liach at openjdk.org> wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>>
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with an annotation. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>>
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>>
>> In addition, I have a question: in [8161245](https://bugs.openjdk.org/browse/JDK-8161245) it seems some fields can be optimized as seen in [ciField.cpp](https://github.com/openjdk/jdk/blob/6aec6f3a842ead30b26cd31dc57a2ab268f67875/src/hotspot/share/ci/ciField.cpp#L219). Does it affect the execution performance of MethodHandle in hidden classes' Condy vs. MethodHandle in regular final field in hidden classes?
>>
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>
> - Nuke WrapperInstance
> - Merge branch 'master' into explore/mhp-iface
> - Whitespace, cleanup, rename benchmarks to be informative
> - Address review comments
>
> Make sure it runs with SecurityManager
> Split the benchmarks
> - Use a dumper for interface instances, other cleanup
> - Merge branch 'master' into explore/mhp-iface
> - Merge branch 'master' into explore/mhp-iface
> - Remove unused JavaLangReflectReflectAccess.invokeDefault
> - rethrow error
> - Benchmark compareing to lamda metafactory, various minor updates
> - ... and 7 more: https://git.openjdk.org/jdk/compare/d7a90082...3fe36fd6
If you run the test with the system property on, it's dumped in the scratch directory. Do you run with jtreg command?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1499438370
More information about the core-libs-dev
mailing list