On Thu, 1 Jun 2023 15:17:41 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
>> MethodHandleProxiesAsIFInstanceCreat...
>
> Chen Liang has updated the pull request with a new target base due to a merge 
> or a rebase. The incremental webrev excludes the unrelated changes brought in 
> by the merge/rebase. The pull request contains 36 additional commits since 
> the last revision:
> 
>  - 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
>  - stupid faults
>  - Revert to shared-class implementation, found a way to deal with security 
> manager
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/e6f1393e...56a282e4

Thanks for the update.   The security permission check is done regardless of 
whether it passes the access check.    So the generated code can't access 
internal API.   For now, I think you can go back to spin bytecode for the check 
as done in Proxy.  We will consider if it can be replaced by a public API in 
the future.

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

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

Reply via email to