On Sun, 2 Jul 2023 02:05:23 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 44 commits: > > - Merge branch 'master' into explore/mhp-iface > - stage > > Signed-off-by: liach <li...@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
