RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Feb 3 18:25:30 UTC 2016


JDK-8006627 did the JavaLangAccess hack to improve UUID.toString()

    public String toString() {
        char[] chars = new char[36];
        jla.formatUnsignedLong(mostSigBits >> 32, 4, chars, 0, 8);
        chars[8] = '-';
        jla.formatUnsignedLong(mostSigBits >> 16, 4, chars, 9, 4);
        chars[13] = '-';
        jla.formatUnsignedLong(mostSigBits, 4, chars, 14, 4);
        chars[18] = '-';
        jla.formatUnsignedLong(leastSigBits >> 48, 4, chars, 19, 4);
        chars[23] = '-';
        jla.formatUnsignedLong(leastSigBits, 4, chars, 24, 12);
        return jla.newStringUnsafe(chars);

This is a good performance improvement, but it clashes with Compact
Strings which now have to re-compress the resulting char[] array into
byte[]. And we know that UUID would always produce Latin1 String.

In fact, the entire JavaLangAccess.newStringUnsafe is now not doing what
power users would expect: it *does* allocate now! So, we need to phase
out that internal gateway to avoid confusion. UUID is one of these users
(StringJoiner is another).

This is the proposed fix:

My attempts in exposing the entire String coder business to UUID proved
to be rather ugly, so I opted to just all into a single method, and let
java/lang internals to sort this out.

The patch does restore the post-Compact Strings performance, and even
improves it further. See:


More information about the core-libs-dev mailing list