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/d89020de...27e18b7c

src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java 
line 75:

> 73:     public VarHandle withInvokeExactBehavior() {
> 74:         var updatedDelegate = target.withInvokeExactBehavior();
> 75:         return initialized ? new 
> LazyInitializingVarHandle(updatedDelegate, refc) : updatedDelegate;

Suggestion:

        return initialized ? updatedDelegate: new 
LazyInitializingVarHandle(updatedDelegate, refc);


If initialized, should return `updatedDelegate` instead.   Same for 
`withInvokeBehavior`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1214729466

Reply via email to