On Fri, 2 Jun 2023 02:12:30 GMT, Chen Liang <li...@openjdk.org> wrote:
>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`. >> >> A few implementation-detail methods in VarHandle are now documented with the >> implied constraints to avoid subtle problems in the future. Changed >> `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy >> VarHandle changes. Also changed VarHandleBaseTest to report the whole >> incorrect type of exception caught than swallow it and leaving only a >> message. >> >> Current problems: >> - [ ] The lazy var handle is quite slow on the first invocation. >> - As seen in the benchmark, users can first call >> `Lookup::ensureInitialized` to create an eager handle. >> - After that, the lazy handle has a performance on par with the regular >> var handle. >> - [ ] The class-loading-based test is not in a unit test >> - The test frameworks don't seem to offer fine-grained control for >> class-loading detection or reliable unloading >> >> >> Benchmark Mode Cnt Score >> Error Units >> VarHandleLazyStaticInvocation.initializedInvocation avgt 30 12.668 ± >> 0.069 ns/op >> VarHandleLazyStaticInvocation.lazyInvocation avgt 30 12.683 ± >> 0.069 ns/op >> >> >> Benchmark Mode Cnt Score >> Error Units >> LazyStaticColdStart.methodHandleCreateEager ss 10 50.980 ± >> 9.454 us/op >> LazyStaticColdStart.methodHandleCreateLazy ss 10 24.350 ± >> 6.701 us/op >> LazyStaticColdStart.methodHandleInitializeCallEager ss 10 65.140 ± >> 7.552 us/op >> LazyStaticColdStart.methodHandleInitializeCallLazy ss 10 118.360 ± >> 20.320 us/op >> LazyStaticColdStart.varHandleCreateEager ss 10 49.500 ± >> 4.277 us/op >> LazyStaticColdStart.varHandleCreateLazy ss 10 26.690 ± >> 5.157 us/op >> LazyStaticColdStart.varHandleInitializeCallEager ss 10 87.930 ± >> 12.643 us/op >> LazyStaticColdStart.varHandleInitializeCallLazy ss 10 1057.120 ± >> 189.810 us/op > > 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 11 additional commits since > the last revision: > > - Compute base and offset right after linking, simplify code > - Merge branch 'master' into lazy-static-varhandle > - Fix exact swap > > Co-authored-by: Mandy Chung <mandy.ch...@oracle.com> > - Remove export for removed package > - Merge branch 'master' into lazy-static-varhandle > - Test the creation performance of handles, lazy one indeed better > - Merge branch 'master' into lazy-static-varhandle > - copyright year > - Benchmarks. lazy initialize is SLOW > - nuke meaningless overrides > - ... and 1 more: https://git.openjdk.org/jdk/compare/b9ba7a85...27e18b7c Not quite. I mean scenarios like this: import java.lang.invoke.*; class Parent { public static final int[] value = {34}; } class Child extends Parent {} public class Test { public static void main(String... args) throws Throwable { System.out.println(Child.value[0]); var lookup = MethodHandles.lookup(); var getter = lookup.findStaticVarHandle(Child.class, "value", int[].class); System.out.println(((int[]) getter.getAcquire())[0]); } } Here, the `value` field is in parent, but it's accessed via a subclass and is resolved successfully. Are the refc and declaring class still equal here? I think we only need to initialize Parent without initializing Child in this case. I've also updated the benchmark for the latest patch. Unfortunately the regular invocations and lazy var handle initial call performance saw a decrease. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1573054150
