RFR: 8333833: UUID toString removes the use of ByteArrayLittleEndian [v2]

[Chen Liang]

On Sat, 8 Jun 2024 15:51:13 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comments
>
> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 117:
> 
>> 115: 
>> 116:     /**
>> 117:      * Insert the int into the buffer as 4 hexadecimal digits
> 
> 4 hex digits is 2 bytes, right? 
> should this take a short instead?
> At a minimum, seems documentation should be clear as to which 2 bytes are used.

Yes, 4 hex digits requires 2 bytes of input integer; we always take the least significant bytes. I think taking an int is better than taking a short, as subint types are int in bytecode, and short's signedness may be bug-prone.

> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 122:
> 
>> 120:      * @param value to convert
>> 121:      */
>> 122:     public static void putHex(byte[] buffer, int off, int i) {
> 
> Should there be 2 methods - for 2 and 4 bytes respectively?
> Does c2 optimize 8 byte writes as well?

The 4-byte unsigned int input for 8-byte write sounds plausible, I personally am fine either with or without it.

> Does c2 optimize 8 byte writes as well?

>From the first few lines of #16245:

> Merging multiple consecutive small stores (e.g. 8 byte stores) into larger stores (e.g. one long store) can lead to speedup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632081700
PR Review Comment: https://git.openjdk.org/jdk/pull/19610#discussion_r1632082369