RFR: 6983726: remove Proxy from MethodHandleProxies.asInterfaceInstance SAM conversion

Johannes Kuhn jkuhn at openjdk.org
Wed Mar 29 00:28:34 UTC 2023


On Mon, 27 Mar 2023 23:34:52 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 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

Changes requested by jkuhn (Author).

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 338:

> 336:                     .aload(1)
> 337:                     .ifThenElse(Opcode.IF_ACMPEQ, CodeBuilder::iconst_1, CodeBuilder::iconst_0)
> 338:                     .ireturn());

The object methods could be left untouched, as the class inherits the default implementation from `java.lang.Object`. Interfaces can't have default methods with those signatures.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 386:

> 384:         try {
> 385:             return IMPLEMENTATION_INFOS.get(anno.implementedType()).resultClass == clz;
> 386:         } catch (Throwable ex) {

Again, rethrow `Error`s.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 399:

> 397:         try {
> 398:             ret = IMPLEMENTATION_INFOS.get(anno.implementedType());
> 399:         } catch (Throwable ex) {

As mentioned by others, propagate `Error`s.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 422:

> 420:         try {
> 421:             return (MethodHandle) t.getTarget.invokeExact(x);
> 422:         } catch (Throwable ex) {

Propagate `Error`s.

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

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1362084946
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151272557
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151274364
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151273360
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151274996


More information about the core-libs-dev mailing list