RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

[Steven Schlansker]

> On Dec 4, 2017, at 3:46 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> The code in Long.fastUUID is indeed ugly.  I've never heard of UUID
> creation being a bottleneck.  At Google it sometimes seems all our java
> performance problems are with zip file manipulation.

At $MY_WORK, we never use Zip files, but indeed ran into some really nasty
performance bottlenecks in UUID, and cared enough to whine about it and
get it fixed ;)

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013494.html
http://bugs.java.com/view_bug.do?bug_id=JDK-8006627

While I doubt a single string allocation is make or break for us (by far the
bigger problem was the truly awful use of regex and tons of intermediate arrays)
but UUID is a core data type and people expect it to be reasonably performant.