RFR: 8307352: AARCH64: Improve itable_stub [v8]

[Andrew Haley]

On Tue, 29 Aug 2023 07:08:45 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> I want to avoid modifying the assembler_aarch64.hpp file within this change, so I add guarantee in lookup_interface_method.
>> By the way, [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp) contains 100+ assert calls and 34 guarantee calls. I think more cases can be changed, although I am not sure what the rule is for using this or that call.
>
>> By the way, [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp) contains 100+ assert calls and 34 guarantee calls. I think more cases can be changed, although I am not sure what the rule is for using this or that call.
> 
> A JBS issue?

No, I don't think so.

The balance between `assert()` and `guarantee()` is a matter of judgement, not hard rules. 

We don't want to do consistency checking at runtime if we can avoid it, because it adds to startup time.

The `guarantee()` that an operand fits into its field in an instruction has proved its worth, many times. This is because AArch64 has a variety of offset fields, and these are  of varying lengths. It's very easy to be caught out, and sometimes this has happened even after release.

In most other places, an `assert()` is all we need. This is because the thing being asserted doesn't vary much, and we only need to check it once, when we run a debug build.

In the case of checking that the shift in a memory-access instruction matches the operand size, the check will be inlined. I haven't looked, but I expect it will be eliminated by the C++ optimizer at compile time.

In the case of the ldr instruction here, the operand size is determined already by the `ldr` instruction: it's `wordSize`. It cannot be anything else. The AArch64 back end asserts that elsewhere: 


  int vte_size    = vtableEntry::size_in_bytes();
  assert(vte_size == wordSize, "else adjust times_vte_scale");

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

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