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