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

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


Hi,

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

    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:
  http://cr.openjdk.java.net/~shade/8148936/webrev.01/

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:
  http://cr.openjdk.java.net/~shade/8148936/notes.txt

Cheers,
-Aleksey




More information about the core-libs-dev mailing list