Patch to improve primitives Array.sort()

Rezaei, Mohammad A. Mohammad.Rezaei at
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.


>-----Original Message-----
>From: Paul Sandoz [mailto:paul.sandoz at]
>Sent: Friday, May 22, 2015 4:02 AM
>To: Rezaei, Mohammad A. [Tech]
>Cc: 'core-libs-dev at 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>
>> 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
>MAX_RUN_LENGTH was ever there in the first place. AFAICT it was empirically
>But there is no further information as to why this particular behaviour was
>Is there something about an equals-run > MAX_RUN_LENGTH (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 <pair-flip> + <equals> [+ <pair-flip>] for a total
>number of runs < MAX_RUN_COUNT (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.

More information about the core-libs-dev mailing list