On Tue, 27 Jun 2023 16:33:11 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 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 38 commits:
> 
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove assertion, no longer true with teleport definition in MHP
>  - Fix tabs, and tests about modules and constructor access
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/05e9c41e...07cc1279

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 313:

> 311: 
> 312:     private static ProxyClassInfo getProxyClassInfo(Class<?> intfc) 
> throws IllegalArgumentException {
> 313:         while (true) {

I think this needs to recompute the class value only one time if it finds the 
proxy class is unloaded and the reference is cleared.   The caller and the 
locals are holding a strong reference to the interface and so the newly created 
proxy class won't be GC'ed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1245661519

Reply via email to