Patch to improve primitives Array.sort() (original) (raw)

Rezaei, Mohammad A. Mohammad.Rezaei at gs.com
Fri May 22 13:55:00 UTC 2015

We have a set of JMH tests. We'll work with Sunny to make those part of the webrev (where do they go?) and the specific test you suggested below.

Thanks Moh

-----Original Message----- From: Paul Sandoz [mailto:paul.sandoz at oracle.com] Sent: Friday, May 22, 2015 4:02 AM To: Rezaei, Mohammad A. [Tech] Cc: 'core-libs-dev at openjdk.java.net Libs'; Chan, Sunny [Tech]; O'Leary, Kristen [Tech] Subject: Re: Patch to improve primitives Array.sort()

On May 22, 2015, at 1:52 AM, "Rezaei, Mohammad A." <Mohammad.Rezaei at gs.com> wrote: Thanks Paul. Your proposed changes make sense to us and they have no discernable impact on the performance.

Great, thanks. I am happy to update the current webrev (and also create an associated issue). Sorry to drag this out a little more, but i am still curious as to why MAXRUNLENGTH was ever there in the first place. AFAICT it was empirically derived: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011- February/005821.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2011- January/005713.html But there is no further information as to why this particular behaviour was required. Is there something about an equals-run > MAXRUNLENGTH (33) where an optimized merge sort performs poorly? I could have missed something but i don't see any data in either of the sorting tests that would exercise this case. Perhaps we need to performance test against a data set of + [+ ] for a total number of runs < MAXRUNCOUNT (67) ? More generally it's probably worth investing in a set of related JMH tests based on Sorting test combinations and data shapes, as we don't currently have easy visibility into performance regressions due to code changes or perhaps due to changes in hotspot. Paul.

More information about the core-libs-dev mailing list