> 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
Chen Liang has updated the pull request incrementally with one additional commit since the last revision: rethrow error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13197/files - new: https://git.openjdk.org/jdk/pull/13197/files/0158ffe5..fade6200 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197 PR: https://git.openjdk.org/jdk/pull/13197
