RFR: 8369828: Generalize share/utilities/bytes.hpp [v2]

[Justin King]

On Tue, 14 Oct 2025 17:57:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Qualify identifiers
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/utilities/bytes.hpp line 81:
> 
>> 79: 
>> 80:     if (Endian::is_Java_byte_ordering_different()) {
>> 81:       x = byteswap(x);
> 
> If a little-endian platform doesn't support unaligned accesses, this
> restucturing results in this being a byteswap of a byte-by-byte copied value.
> Are compilers smart enough to merge those? I think affected platforms are arm,
> riscv64, and zero. The old arm and zero code avoids calling byteswap. The old
> riscv64 does just use the byteswap approach.

Godbolt

Clang ARM 32-bit:



new_get_Java_u4(void const*):
        ldrb    r1, [r0]
        ldrb    r2, [r0, #1]
        ldrb    r3, [r0, #2]
        ldrb    r0, [r0, #3]
        orr     r1, r1, r2, lsl #8
        orr     r0, r3, r0, lsl #8
        orr     r0, r1, r0, lsl #16
        rev     r0, r0
        bx      lr

old_get_Java_u4(unsigned char*):
        ldrb    r2, [r0, #1]
        ldrb    r1, [r0]
        ldrb    r3, [r0, #2]
        lsl     r2, r2, #16
        orr     r1, r2, r1, lsl #24
        ldrb    r0, [r0, #3]
        orr     r1, r1, r3, lsl #8
        orr     r0, r1, r0
        bx      lr


GCC ARM 32-bit:


new_get_Java_u4(void const*):
        ldr     r0, [r0]  @ unaligned
        rev     r0, r0
        bx      lr
old_get_Java_u4(unsigned char*):
        ldr     r0, [r0]  @ unaligned
        rev     r0, r0
        bx      lr

> src/hotspot/share/utilities/unalignedAccess.hpp line 53:
> 
>> 51:   static void store(void* ptr, T value) {
>> 52:     STATIC_ASSERT(std::is_trivially_copyable<T>::value);
>> 53:     STATIC_ASSERT(std::is_trivially_default_constructible<T>::value);
> 
> I'm not seeing why we should care about trivially default-constructible here?

This is more just for language correctness, in case somebody tries to use this with a class or struct that is non-trivial.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2432636278
PR Review Comment: https://git.openjdk.org/jdk/pull/27801#discussion_r2432638366