RFR: 8291065: Creating a VarHandle for a static field triggers class initialization [v5]

[Chen Liang]

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/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