RFR: 8291065: Creating a VarHandle for a static field triggers class initialization
Maurizio Cimadamore
mcimadamore at openjdk.org
Fri May 5 13:06:23 UTC 2023
On Fri, 5 May 2023 04:48:09 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 0.769 ± 0.003 ns/op
> VarHandleLazyStaticInvocation.lazyInvocation avgt 30 0.767 ± 0.002 ns/op
> VarHandleLazyStaticCreation.eagerInitialize ss 10 348580.000 ± 115234.161 ns/op
> VarHandleLazyStaticCreation.lazyInitialize ss 10 961670.000 ± 154813.238 ns/op
src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 74:
> 72: @Override
> 73: public boolean isAccessModeSupported(AccessMode accessMode) {
> 74: var directTarget = this.directTarget;
Why is this not defined in the superclass, and then use `asDirect` (as done in other cases) ?
src/java.base/share/classes/java/lang/invoke/VarHandles.java line 110:
> 108: }
> 109: else {
> 110: if (UNSAFE.shouldBeInitialized(refc)) {
This seems unrelated to the issue this PR is really about (if I understand correctly). Would it make sense to address this as part of another PR?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186067149
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186068196
More information about the core-libs-dev
mailing list