RFR: 8307352: AARCH64: Improve itable_stub

Boris Ulasevich bulasevich at openjdk.org
Tue Jun 20 08:10:06 UTC 2023


On Fri, 16 Jun 2023 16:21:53 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 
>> 
>> The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass.
>> 
>> InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures:
>> 
>> 
>> Cortex-A53 (Pi 3 Model B Rev 1.2)
>> 
>> test1stInt2Types    37.5      37.358     0.38
>> test1stInt3Types   160.166   148.04      8.19
>> test1stInt5Types   158.131   147.955     6.88
>> test2ndInt2Types    52.634    53.291    -1.23
>> test2ndInt3Types   201.39    181.603    10.90
>> test2ndInt5Types   195.722   176.707    10.76
>> testIfaceCall      157.453   140.498    12.07
>> testIfaceExtCall   175.46    154.351    13.68
>> testMonomorphic     32.052    32.039     0.04
>>                                  AVG:    6.85
>> 
>> Cortex-A72 (Pi 4 Model B Rev 1.2)
>> 
>> test1stInt2Types    27.4796   27.4738    0.02
>> test1stInt3Types    66.0085   64.9374    1.65
>> test1stInt5Types    67.9812   66.2316    2.64
>> test2ndInt2Types    32.0581   32.062    -0.01
>> test2ndInt3Types    68.2715   65.6643    3.97
>> test2ndInt5Types    68.1012   65.8024    3.49
>> testIfaceCall       64.0684   64.1811   -0.18
>> testIfaceExtCall    91.6226   81.5867   12.30
>> testMonomorphic     26.7161   26.7142    0.01
>>                                  AVG:    2.66
>> 
>> Neoverse N1 (m6g.metal)
>> 
>> test1stInt2Types     2.9104    2.9086    0.06
>> test1stInt3Types    10.9642   10.2909    6.54
>> test1stInt5Types    10.9607   10.2856    6.56
>> test2ndInt2Types     3.3410    3.3478   -0.20
>> test2ndInt3Types    12.3291   11.3089    9.02
>> test2ndInt5Types    12.328    11.2704    9.38
>> testIfaceCall       11.0598   10.3657    6.70
>> testIfaceExtCall    13.0692   11.2826   15.84
>> testMonomorphic      2.2354    2.2341    0.06
>>                                  AVG:    6.00
>> 
>> Neoverse V1 (c7g.2xlarge)
>> 
>> test1stInt2Types    2.2317     2.2320   -0.01
>> test1stInt3Types    6.6884     6.1911    8.03
>> test1stInt5Types    6.7334     6.2193    8.27
>> test2ndInt2Types    2.4002     2.4013   -0.04
>> test2ndInt3Types    7.9603     7.0372   13.12
>> test2ndInt5Types    7.9532     7.0474   12.85
>> testIfaceCall       6.7028     6.3272    5.94
>> testIfaceExtCall    8.3253     6.941...
>
> src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp line 197:
> 
>> 195:   // Receiver subtype check against REFC.
>> 196:   // Get selected method from declaring class and itable index
>> 197:   __ lookup_interface_method_stub(recv_klass_reg, holder_klass_reg, resolved_klass_reg, rmethod,
> 
> Can this optimization be applied to `TemplateTable::invokeinterface`? It also has two calls of `lookup_interface_method`.

Yes, there are similar calls to lookup_interface_method stubs from TemplateTable::invokeinterface and from VtableStubs::create_itable_stub. Unfortunately, the instructions in between the lookup_interface_method calls are different, making it difficult to create a common stub for them. Performance is not an issue for the interpreter. I think the dilemma is: (1) create a new but complicated common stub vs. (2) add a faster implementation for VtableStubs, and leave the TemplateTable implementation intact. At the moment, I prefer the second way. Let me create a JBS issue with the idea of switching TemplateTable::invokeinterface (both aarch and x86 impl) to a new implementation if anyone encounters the problem of TemplateTable::invokeinterface performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1234897156


More information about the hotspot-dev mailing list