RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance [v16]
Maurizio Cimadamore
mcimadamore at openjdk.org
Mon May 8 09:35:33 UTC 2023
On Sun, 7 May 2023 13:34:54 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 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
More information about the core-libs-dev
mailing list