RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance [v11]

[Chen Liang]

On Mon, 1 May 2023 14:56:27 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 a check to the class data. 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.
>> 
>> [^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 24 additional commits since the last revision:
> 
>  - Renames
>  - Merge branch 'master' into explore/mhp-iface
>  - Consolidate iteration over public methods
>  - Define MH proxy class in a dynamic module
>  - Fix test that depend on WrapperInstance
>  - Require an original lookup in constructor arguments to prevent unintended instantiation
>  - pass interface info via condy,
>    drop explicit ea flags
>    initialize benchmark work variable randomly
>    benchmarks just need 1 fork
>  - Nuke WrapperInstance
>  - Merge branch 'master' into explore/mhp-iface
>  - Whitespace, cleanup, rename benchmarks to be informative
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a52adfb8...f5d0ef0a

1. About moving the checker method to another existing class: Security Manager denies calls to conditionally-exported java.base internal packages, should I spin a utility class in a new module on initialization and export that module to the generated proxy classes, or pass a live methodhandle to the validation method to the class?
2. Another question for Project Leyden: does it aim to further reduce the number of LambdaForm-compiled invoker classes generated as well, especially customized LambdaForms?

I think I will try add a benchmark that measures the cold-start and creation performance for the proxies, especially for the shared-class implementation; at least the proxy-based implementation has negligible creation performance compared to the dedicated-class implementation last I tested. Also as a side note, class definition does bring a huge creation-time overhead: it takes 25000 ns to create a dedicated instance, but only 20ns to create a shared instance. The dedicated-class implementation has no advantage besides the blazingly-fast invocation performance for non-constant instances.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1532146903