RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout
paul.sandoz at oracle.com
Fri Jan 29 17:21:40 UTC 2016
> 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).
>> 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.
More information about the core-libs-dev