RFR 8073124: Tune test and document TimSort runs length stack size increase

[David Holmes]

On 16/02/2015 9:20 PM, David Holmes wrote:
> On 16/02/2015 6:59 PM, Lev Priima wrote:
>> Thanks, David,
>> Could you please push it ?
>
> I will if Roger doesn't get to it first. It'll be 11 hours before I can
> push it.

This has been pushed but note there is a minor issue with the test. The 
jtreg tag specification doesn't terminate tags on newlines, they 
continue until the next tag is encountered or the end of the comment. 
Consequently this:

  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
  * not for regular execution on all platforms:
  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
  * run main/othervm -Xmx16g TimSortStackSize2 2147483644

is processed as:

@run main/othervm -Xmx385m TimSortStackSize2 67108864 not for regular 
execution on all platforms: run main/othervm -Xmx8g TimSortStackSize2 
1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644

and so TimSortStackSize2 is invoked with 18 arguments.

David
-----

> David
>
>> Lev
>>
>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>> Please review and push:
>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>
>>> I hadn't realized 8072909 had been pushed without final reviewer
>>> comments being addressed. :(
>>>
>>> These changes seem okay. I hope they get promoted at the same time as
>>> the original changeset so we don't get test failures.
>>>
>>> Thanks,
>>> David
>>>
>>>> Lev
>>>>
>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>> Hi Lev,
>>>>>
>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>> Christos,
>>>>>>
>>>>>> Test may fail on shorter arrays(page 8 of paper). For instance, on
>>>>>> worst
>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[]) works
>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>
>>>>> I'd also like to see this documented somewhere in the code. Presently
>>>>> there is a reference to listsort.txt but then you have to go and find
>>>>> it on the web. :( At a minimum could we please add:
>>>>>
>>>>>  175          * computation below must be changed if MIN_MERGE is
>>>>> decreased.  See
>>>>>  176          * the MIN_MERGE declaration above for more information.
>>>>> +             * The maximum value of 49 allows for an array up to
>>>>> length
>>>>> +             * Integer.MAX_VALUE-4.
>>>>>
>>>>>> Roger, David,
>>>>>> I've updated the test (
>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> ) to make it more suitable for regular execution:
>>>>>>
>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>
>>>>> This will still fail on small memory devices:
>>>>>
>>>>> :~> java TimSortStackSize2 67108864
>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>>>>
>>>>> as the default heap ergonomics may not be large enough. I had to add a
>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>>    28  * not for regular execution on all platforms:
>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>
>>>>>> Could you please push this:
>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>> ?
>>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>
>>>>>>> | Ok - thanks Lev!
>>>>>>> |
>>>>>>> | David
>>>>>>>
>>>>>>> For posterity can someone document this, and also the value for
>>>>>>> which
>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>
>>>>>>> christos
>>>>>>
>>>>
>>