Re: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string
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. Mile On Feb 3 2013, at 21:26 , Steven Schlansker wrote: On Feb 1, 2013, at 11:42 AM, Mike Duigou mike.dui...@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! Hi, Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: http://dl.dropbox.com/u/1422321/uuid_webrev/index.html http://dl.dropbox.com/u/1422321/uuid_webrev.zip Please let me know if there are any further modifications I should make. Thanks! Steven
Re: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string
On Feb 11, 2013, at 9:04 PM, Mike Duigou mike.dui...@oracle.com wrote: 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. Please let me know if I can be of any help in a way that doesn't actually cost more work than I end up contributing :-) Mile On Feb 3 2013, at 21:26 , Steven Schlansker wrote: On Feb 1, 2013, at 11:42 AM, Mike Duigou mike.dui...@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! Hi, Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: http://dl.dropbox.com/u/1422321/uuid_webrev/index.html http://dl.dropbox.com/u/1422321/uuid_webrev.zip Please let me know if there are any further modifications I should make. Thanks! Steven
Re: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string
On Feb 1, 2013, at 11:42 AM, Mike Duigou mike.dui...@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! Hi, Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: http://dl.dropbox.com/u/1422321/uuid_webrev/index.html http://dl.dropbox.com/u/1422321/uuid_webrev.zip Please let me know if there are any further modifications I should make. Thanks! Steven
Re: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string
This looks fairly much complete to me. I will run it through the some testing here and then push your patch. Great work and thank you! Mike On Feb 3 2013, at 21:26 , Steven Schlansker wrote: On Feb 1, 2013, at 11:42 AM, Mike Duigou mike.dui...@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! Hi, Here are the updates to the webrev. I hope the changes are in line with what you'd had in mind: http://dl.dropbox.com/u/1422321/uuid_webrev/index.html http://dl.dropbox.com/u/1422321/uuid_webrev.zip Please let me know if there are any further modifications I should make. Thanks! Steven
