RFR(S) 8252311: AArch64: save two words in itable lookup stub

Andrew Haley aph at redhat.com
Wed Sep 2 07:51:46 UTC 2020


On 30/08/2020 18:18, Boris Ulasevich wrote:
>
> The interface method lookup stub becomes hot when interface calls
> are performed frequently. The stub assembly code can be made
> shorter (132->124 bytes) by using a pre-increment instruction variant.

These things change over time. There was a time when loads with
writeback were deprecated because they took extra clock cycles. On
some machines, particularly big OOO machines, that might not matter.

> http://cr.openjdk.java.net/~bulasevich/8252311/webrev.00
> http://bugs.openjdk.java.net/browse/JDK-8252311
>
> The benchmark [1] shows [2] performance and icache loads improvement:
> performance: 6165206 -> 6307798 ops/s
> L1-icache-loads: 307.271 -> 274.604
>
> The change was tested with JTREG.

This is a change that may or may not make things better.  Either way
the benefit is so small that it is in the noise, as Andrew Dinn said.

We have to think carefully about such things. AArch64 is an
architecture, not a processor, and small benefits one one
implementation might be small (or even large) losses on others.

We need a clean AArch64 back end that generates simple and generally
efficient code. What we don't need is special cases for different
microarchitectures, because the back end will become unmaintainable,
and very hard to test in all combinations.

Go ahead, commit this. I think it's a small improvement, and the code
is easier to understand. But every change carries some risk, and I'm
going to start pushing back on changes that don't seem to offer much
benefit.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671




More information about the hotspot-compiler-dev mailing list