RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance [v21]

[Chen Liang]

On Thu, 6 Jul 2023 16:12:15 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 for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ±     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ±     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ±     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ±     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ±     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ±     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ±     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ±     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ±     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ±     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ±     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ±     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ±     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ±     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ±     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:
> 
>  - Spec update, also fix broken null behaviors
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'mh-proxies' of https://github.com/mlchung/jdk into explore/mhp-iface
>  - store a WeakReference holder in the class value
>  - Merge branch 'master' into explore/mhp-iface
>  - stage
>    
>    Signed-off-by: liach <liach at users.noreply.github.com>
>  - Review comments
>  - Code cleanup, thanks mandy!
>  - Merge branch 'master' of https://github.com/openjdk/jdk into explore/mhp-iface
>  - 1. Change WRAPPER_TYPES to WeakHashMap to accurately determine if the given class is
>       the proxy class
>    
>    Discussion:
>    2. I dropped ProxyClassInfo and use Lookup just to see the simplication.
>       If wrapperInstanceTarget and wrapperInstanceType are frequently called, it makes
>       sense to cache the method handles.
>    
>    3. Should it use SoftReference or WeakReference?  It depends if asInterfaceInstance
>       will be used heavily.
>    
>    3. I also dropped SamInfo and getStats as it can be inlined in the caller, which
>       I think it's clearer to see what it does in place.
>  - ... and 38 more: https://git.openjdk.org/jdk/compare/97e99f01...571e1fa6

The spec change was for:
1. The spec is already updated for the hidden class IAE requirement, which is already the existing behavior (from j.l.r.Proxy)
2. That Jorn suggests to change implNote.

If I revert the spec changes, I will revert the IAE for hidden interface note as well; it's already existing behavior. I will adjust the CSR to be purely behavioral for the differences under reflection inspection (Object vs Proxy superclass, no more marker interfaces)

I think the spec in baseline is consistent with the implementation, both new and old. I think the spec itself does need some update, like the `Class::forName` specification: it has a few redundancies and inaccuracies.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1624546415