RFR: 8291065: Creating a VarHandle for a static field triggers class initialization [v5]
Mandy Chung
mchung at openjdk.org
Fri Jun 2 22:53:22 UTC 2023
On Fri, 2 Jun 2023 02:12:30 GMT, Chen Liang <liach at 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.chung at 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/01dce019...27e18b7c
what performance results do you see with this change?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574406514
More information about the core-libs-dev
mailing list