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

Dmitry Fazunenko dmitry.fazunenko at oracle.com
Thu Dec 25 11:53:09 UTC 2014


Hi Michail,

I strongly believe, that the right way to fix this issue is adding 
@requires as you proposed originally.
If one specifies external VM options it is expected that all tested VM 
will be run with those options.
If a test can't be run with some options, adding @requires will help to 
not run.
Trying to alter the external flags within tests is like a hack we had to 
do to avoid failures. Before @requires there wasn't another alternative.
But now, we have got a mechanism to express that a test doesn't work 
with certain options. Let's use it.

Thanks,
Dima


On 24.12.2014 17:42, Michail Chernov wrote:
> Hi,
>
> Please take a look at this fix.
>
> Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8066122
>
> Thanks,
> Michail
>
>
> On 22.12.2014 17:21, Michail Chernov wrote:
>> Hi Kim,
>>
>> About jtreg and options filtering out - I know that Boolean options 
>> filtering is not bug, it is feature. For example, in case if we 
>> define -XX:+SomeImportanatOptionForThisTest for testing and this 
>> options is undefined by VM flags which we define during testing, it 
>> causes to wrong test result.
>>
>> I looked through other tests and found that I was wrong - improvement 
>> for test failure is more simpler than I thought. Currently I don't 
>> make any change in testlibrary.
>>
>> Suggestid fix is to add -XX:-ExplicitGCInvokesConcurrentto all 
>> RunUtil.runTestClearGcOpts and RunUtil.runTestKeepGcOpts invocation.
>>
>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/
>>
>> Thanks,
>> Michail
>>
>> On 17.12.2014 20:33, Kim Barrett wrote:
>>> [This is still not a real review, just kibitzing so far - I’ve 
>>> looked at the changes, but don’t yet feel I understand the 
>>> surrounding code well enough to say I’ve reviewed them.]
>>>
>>> On Dec 17, 2014, at 11:01 AM, Michail Chernov 
>>> <michail.chernov at oracle.com> wrote:
>>>> 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.
>>> That bit about jtreg filtering out -XX:-ExplicitGCInvokesConcurrent 
>>> seems backward, at least for a case like this.  I wouldn’t have 
>>> expected global options applicable to all tests to override 
>>> test-specific arguments. Also, it would seem that would make the 
>>> other tests my earlier comment was referring to not work either.  So 
>>> I’m confused about why there’s all this extra filtering going on in 
>>> this change and why it would be needed.  Unless there are important 
>>> differences in some of the underlying infrastructure, like the 
>>> different testlibrary variants (jdk/test/lib/testlibrary vs 
>>> hotspot’s testlibrary?).  Sorry I’m not being clearer about this - 
>>> I’m suspicious there is a deeper problem, but don’t know enough to 
>>> point to its whereabouts.  (And that’s assuming my suspicions are 
>>> correct, and I’m not just confused.)
>>>
>>>
>>>
>>>
>>
>>
>>
>



More information about the hotspot-gc-dev mailing list