RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent

Michail Chernov michail.chernov at oracle.com
Wed Dec 17 16:01:51 UTC 2014


On 10.12.2014 23:05, Kim Barrett wrote:
> On Dec 3, 2014, at 8:34 AM, Michail Chernov <michail.chernov at oracle.com> wrote:
>> Hi,
>>
>> Please review small fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8066122
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.00/
>>
>> Summary:  CollectionUsageThreshold.java hangs due to VM performs concurrent GC with -XX:+ExplicitGCInvokesConcurrent flag, as result - notification is not received. Excluded test execution with -XX:+ExplicitGCInvokesConcurrent.
>>
>> Thanks,
>> Michail
> In a recent webrev discussion thread I saw the statement:
>
>      Other similar tests that had the same problem has solved this by
>      adding -XX:-ExplicitGCInvokesConcurrent on the command line. My
>      fix here is the same.
>
> If that is indeed the accepted approach, then CollectionUsageThreshold
> should be changed in a similar manner, rather than using @requires.
>
> [I think both approaches have pluses and minuses, but think I mildly
> prefer the argument override approach rather than @requires for this.]
>
>
>

Hi Kim,

Test was fixed, now it excludes -XX:+ExplicitGCInvokesConcurrent option 
from test run.
Also fixed LowMemoryTest.java - it failed with same reason as 
CollectionUsageThreshold.java.

http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/

Function getFilteredTestJavaOpts in Util.java was got from hotspot repo 
http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/ from testlibrary, because 
Util.java in GC and Util.java in Runtime repos are different. This 
function can be useful not only for this case.

Simply adding of -XX:-ExplicitGCInvokesConcurrent won't work because 
JTREG filtersout it in case if -XX:+ExplicitGCInvokesConcurrent is 
defined as VM option.

Thanks,
Michail



More information about the hotspot-gc-dev mailing list