RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout

[Paul Sandoz]

> On 29 Jan 2016, at 17:43, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> 
> 
> On 2016/1/29 20:53, Paul Sandoz wrote:
>>> On 29 Jan 2016, at 13:43, Hamlin Li <huaming.li at oracle.com> wrote:
>>> 
>>> Hi Paul,
>>> 
>>> Sorry for delayed response, have been occupied by other higher priority task.
>>> Thanks for your review, I agree with you that your second approach is better.
>>> New webrev: http://cr.openjdk.java.net/~mli/8076458/webrev.01/
>>> 
>> The changes to the data providers look ok.
>> 
>> Would you mind splitting out the tests between StreamTestData<Integer> and StreamTestData<Integer>.small as outlined in 2) below. That way for the non-eplosive stuff we can still crunch on larger data without much of a slow down.
> Hi Pual,
> 
> Yes, you're right, it does not slow down too much, it cost 15.553 seconds after the first revision(webrev.01), and it cost 16.064 after the second revision(webrev.02).
> Please check the webrev: http://cr.openjdk.java.net/~mli/8076458/webrev.02/ <http://cr.openjdk.java.net/~mli/8076458/webrev.02/>

+1, reviewed. Do you need me to push it?


>>> Below are times cost for different ops:
>>>  total        :169.996
>>>  testOps only    :108.988
>>>  testIntOps only :23.865
>>>  testLongOps only :22.326
>>>  testDoubleOps only :16.944
>>> so, I build small data providers for each of them.
>>> 
>> Ok, and i suspect/hope it drops by at least an order of magnitude with your changes applied.
> Yes, it cost 15.553 seconds after the first revision(webrev.01).

Great.


>> Out of curiosity i wonder what the times would be if using parallel GC rather than G1.
> With different GC options after second revision(webrev.02):
>  -UseParallelGC:  elapsed time (seconds): 16.047
>  +UseParallelGC: elapsed time (seconds): 13.263
>  -UseG1GC:         elapsed time (seconds): 16.612
>  +UseG1GC:        elapsed time (seconds): 16.998
>  -UseParallelOldGC: elapsed time (seconds): 16.039
>  +UseParallelOldGC: elapsed time (seconds): 14.297
> 

Ok, so i suspect in the case of when your patch is not applied the difference is greater in absolute terms and G1 in a sense might be causing such memory intensive tests to slow down.

Paul.