On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang <li...@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 acceptable call and creation 
> performance compared to the baseline; though the methods to access wrapper 
> information see huge performance drops, they are not anticipated to be used 
> in a very frequent basis, while the old implementation's wrapper access 
> methods are more optimized (2ns/op) than interface implementation methods 
> (6ns/op). [Oracle JDK 20 vs 
> this](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> 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.
> 
> Alternative implementation:
> [An alternative 
> implementation](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0)
>  was to generate a proxy class for each methodhandle than sharing across 
> methodhandles. That implementation was abandoned for its bad proxy creation 
> performance, despite it having excellent call performance. [Alternative 
> implementation vs 
> this](https://jmh.morethan.io/?gists=08abb39f224574550925beb8be1b2f59,e5115a2a8fa0a45159e15fab0d95b5d8)
> 
> 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

> I believe you can have better performance if you pass the method handle as 
> the class data of the hidden class and you load it with a constant dynamic 
> [https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte[],java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClassWithClassData(byte%5B%5D,java.lang.Object,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...))
>  and 
> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/invoke/MethodHandles.html#classData(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class)

With one class per method handle + classdata, you do have better performance 
for invocations, but the penalties on creation is insurmountable: [JMH results 
comparison](https://jmh.morethan.io/?gists=bf98de7b2128e7e5d14e697fd9921eb9,08abb39f224574550925beb8be1b2f59)
 between OracleJDK 20 and [my initial 
patch](https://github.com/openjdk/jdk/commit/72dbf9d4e01c455854d9b865cb2a47c38f37a8e0),
 implemented based on this idea

> EDIT: you may have to use invokedynamic instead of a ldc constant dynamic + 
> invokeExact() because the interface can have several methods to implement due 
> to bridge methods (inheritance + generics)

Since this API needs to call `asType` on the input method handle to perform 
input validation, I just decided to pass the validated method handles wholesale 
to the generated class, either as condy (initial patch) or constructor 
arguments.

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

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

Reply via email to