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

Steven Schlansker stevenschlansker at gmail.com
Tue Dec 5 00:24:54 UTC 2017

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.

More information about the core-libs-dev mailing list