RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter [v2]

Mandy Chung mchung at openjdk.java.net
Tue Feb 8 17:43:11 UTC 2022


On Tue, 8 Feb 2022 17:11:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`.
>> 
>> There is direct VarHandle benchmark in our corpus:
>> 
>> 
>> $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint"
>> 
>> Benchmark                                 Mode  Cnt     Score    Error  Units
>> 
>> # -Xint
>> # Baseline
>> VarHandleExact.exact_exactInvocation      avgt   30   714.041 ±  5.882  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30   641.570 ± 11.681  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  1336.571 ± 11.873  ns/op
>> 
>> # -Xint
>> # Patched
>> VarHandleExact.exact_exactInvocation      avgt   30   678.495 ± 10.752  ns/op ; +5%
>> VarHandleExact.generic_exactInvocation    avgt   30   573.320 ±  5.100  ns/op ; +11%
>> VarHandleExact.generic_genericInvocation  avgt   30  1338.593 ± 14.275  ns/op 
>> 
>> # (server, default)
>> # Baseline
>> VarHandleExact.exact_exactInvocation      avgt   30   0.620 ± 0.079  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30   0.602 ± 0.063  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  10.521 ± 0.065  ns/op
>> 
>> # (server, default)
>> # Patched
>> VarHandleExact.exact_exactInvocation      avgt   30   0.621 ± 0.070  ns/op
>> VarHandleExact.generic_exactInvocation    avgt   30   0.601 ± 0.061  ns/op
>> VarHandleExact.generic_genericInvocation  avgt   30  10.499 ± 0.070  ns/op
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_64 fastdebug `tier2`
>>  - [x] Linux x86_64 fastdebug `tier3`
>
> Aleksey Shipilev 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 three additional commits since the last revision:
> 
>  - Comment
>  - Merge branch 'master' into JDK-8281168-int-varform
>  - Fix

This change looks okay.    One biggest cold startup overhead we measured for JEP 416 is due to the overhead of spinning and loading classes of MH/VH.      This micro-optimization focuses on the performance of VH invocation.    Do you see  class spinning and loading from your benchmark?   Maybe in the generic invocation case?

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

PR: https://git.openjdk.java.net/jdk/pull/7333


More information about the core-libs-dev mailing list