RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance [v20]
Jorn Vernee
jvernee at openjdk.org
Tue Jul 4 15:11:20 UTC 2023
On Sun, 2 Jul 2023 02:05:23 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 44 commits:
>
> - 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.
> - 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
> - ... and 34 more: https://git.openjdk.org/jdk/compare/0e3d91dc...44e62271
Overall the latest version looks really good. Thanks!
src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 186:
> 184: * Discussion:
> 185: * Since project leyden aims to improve startup speed, asInterfaceInstance
> 186: * will share one implementation class for each interface than one implementation
Suggestion:
* will share one implementation class for each interface rather than one implementation
src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 324:
> 322: r = PROXY_LOOKUPS.get(intfc);
> 323: }
> 324: return r.get();
This doesn't look right to me. AFAICT the Lookup can be GC'd before we call `get`.
> No, it wouldn't. PROXY_LOOKUPS.get(intfc) returns the WeakReference of the lookup class which is strongly reachable in the stack frame.
I'm not sure how the lookup class (`intfc` ?) is keeping the `Lookup` alive here?
-------------
PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1512911743
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1252043160
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1252085215
More information about the core-libs-dev
mailing list