On Wed, 29 Mar 2023 00:13:56 GMT, Johannes Kuhn <jk...@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 > > 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. Do interfaces still implement these properly without definition if they extend interfaces that declare `@Override boolean equals();` etc.? > 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. This is already obsolete by https://github.com/liachmodded/jdk/commit/821d6b382aeceb70c67c59771deb7438f3b4b7fd, which I plan to push soon. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151277383 PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1151277583
