Hi Aleksey!
Looks good to me!
Two minorish comments
1)
431 formatUnsignedLong0(lsb >> 48, 4, buf, 19, 4);
I would suggest using unsigned shift >>> here just to avoid thinking
about whether the sign matters or not.
Not a big deal, of course.
2)
Do you want to add the bug id 8148936 to the @bug list in the regression
test?
Sincerely yours,
Ivan
On 03.02.2016 21:25, Aleksey Shipilev wrote:
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
