RFR: 8311207: Cleanup for Optimization for UUID.toString [v15]

[Claes Redestad]

On Tue, 12 Sep 2023 22:44:35 GMT, 温绍锦 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 112:
>> 
>>> 110:                 | (DIGITS[b1 & 0xff] << 16)
>>> 111:                 | (((long) DIGITS[b2 & 0xff]) << 32)
>>> 112:                 | (((long) DIGITS[b3 & 0xff]) << 48);
>> 
>> Can you reverse the order of these source lines to put the shifts of the higher order bits before the lower order bit shifts.  `3333222211110000`. Its easier to understand where the bits end up in the long.
>> The rest of the change is better focused.
>
> if reverse packDigits order, performance will be slow, I don't know why yet.
> 
> The following is the data running on MacBookPro M1 Max :
> 
> make test TEST="micro:java.util.UUIDBench.toString"
> 
> Benchmark           (size)   Mode  Cnt   Score   Error   Units (current order 4f6ed3e6)
> UUIDBench.toString   20000  thrpt   15  96.396 ? 0.946  ops/us
> 
> 
> Benchmark           (size)   Mode  Cnt   Score   Error   Units (reverse packDigits order)
> UUIDBench.toString   20000  thrpt   15  86.496 ? 0.542  ops/us

Looks like something that might be an interesting puzzler for JIT compiler folks. Perhaps added implicit casts to long messes something up?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1323773899