On Sun, 7 May 2023 13:34:54 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 updates the WrapperInstance methods to take an `Empty` to avoid method >> clashes >> 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 faster than old implementation in general. >> >> >> Benchmark Mode Cnt >> Score Error Units >> MethodHandleProxiesAsIFInstance.baselineAllocCompute avgt 15 >> 1.483 ± 0.025 ns/op >> MethodHandleProxiesAsIFInstance.baselineCompute avgt 15 >> 0.264 ± 0.006 ns/op >> MethodHandleProxiesAsIFInstance.testCall avgt 15 >> 1.773 ± 0.040 ns/op >> MethodHandleProxiesAsIFInstance.testCreate avgt 15 >> 16.754 ± 0.411 ns/op >> MethodHandleProxiesAsIFInstance.testCreateCall avgt 15 >> 19.609 ± 1.598 ns/op >> MethodHandleProxiesAsIFInstanceCall.callDoable avgt 15 >> 0.424 ± 0.024 ns/op >> MethodHandleProxiesAsIFInstanceCall.callHandle avgt 15 >> 1.936 ± 0.008 ns/op >> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance avgt 15 >> 1.766 ± 0.014 ns/op >> MethodHandleProxiesAsIFInstanceCall.callLambda avgt 15 >> 0.414 ± 0.005 ns/op >> MethodHandleProxiesAsIFInstanceCall.constantDoable avgt 15 >> 0.271 ± 0.006 ns/op >> MethodHandleProxiesAsIFInstanceCall.constantHandle avgt 15 >> 0.263 ± 0.004 ns/op >> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance avgt 15 >> 0.266 ± 0.005 ns/op >> MethodHandleProxiesAsIFInstanceCall.constantLambda avgt 15 >> 0.262 ± 0.003 ns/op >> MethodHandleProxiesAsIFInstanceCall.direct avgt 15 >> 0.264 ± 0.005 ns/op >> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance avgt 15 >> 18.000 ± 0.181 ns/op >> MethodHandleProxiesAsIFInstanceCreate.createCallLambda avgt 15 >> 17624.673 ± 2404.853 ns/op >> MethodHandleProxiesAsIFInstanceCreate.createInterfaceInstance avgt 15 >> 17.554 ± 0.748 ns/op >> MethodHandleProxiesAsIFInstanceCreate.createLambda avgt 15 >> 16860.341 ± 1270.982 ns/op >> MethodHandleProxiesSuppl.testInstanceTarget avgt 15 >> 0.405 ± 0.006 ns/op >> MethodHandleProxiesSuppl.testInstanceType avgt 15 >> 0.343 ± 0.005 ns/op >> MethodHandleProxiesSuppl.testIsWrapperInstance avgt 15 >> 0.375 ± 0.021 ns/op >> >> >> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's >> no longer applicable. >> >> [^1]: single abstract method > > Chen Liang has updated the pull request incrementally with one additional > commit since the last revision: > > Remove assertion, no longer true with teleport definition in MHP src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 342: > 340: > 341: // individual handle fields > 342: clb.withField(ORIGINAL_TARGET_NAME, CD_MethodHandle, > ACC_PRIVATE | ACC_FINAL); Would a @Stable field help here? E.g if the returned functional interface instance is stored in a `static final` field, it should enable better performance? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1187237878
