RFR: 8307352: AARCH64: Improve itable_stub [v8]

[Boris Ulasevich]

On Tue, 29 Aug 2023 08:44:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> 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");

I agree. I keep assert in MacroAssembler::lookup_interface_method_stub and change assert to guarantee in Address::encode.

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

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