RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string
mike.duigou at oracle.com
Tue Feb 12 05:04:35 UTC 2013
I have been following up on this issue. I am going to have to adapt the code a bit because there have been some changes in JDK8.
I won't forget this issue though. It is possible I may not have time to backport it to Java 7.
On Feb 3 2013, at 21:26 , Steven Schlansker wrote:
> On Feb 1, 2013, at 11:42 AM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> I have created another issue 8007398 for the changes to Long. We can even test and push the two issues at the same time. Separating them into two changesets makes the intent easier to follow for future maintainers.
>> We can use the same webrev. There's no need to create another.
>>>> - I would like to see if performed of toString() can be improved further by using String(char value, boolean share) constructor via a sun.miscSharedSecret.JavaLangAccesss method to construct the string directly from the character array. You could test to see if this has positive benefit by temporarily using a static char array.
>>> I will incorporate this into my next revision
>>>> - public static String toString(long msb, long lsb) should be private. There's no compelling reason to add this to the API.
>>>> - Have you run this code against any of the existing regression tests?
>>> Yes, I ran the jtreg UUID and Long tests, all pass. I ran the Apache Harmony UUID test cases against the pre-integrated version of the code. (There should only have been minor modifications since then, variable renamings, whatnot…)
>> OK, once we have a final webrev then I will run final tests and push this!
> Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind:
> Please let me know if there are any further modifications I should make.
More information about the core-libs-dev