RFR: 8062537: [TESTBUG] Conflicting GC combinations in hotspot tests

Evgeniya Stepanova evgeniya.stepanova at oracle.com
Fri Oct 31 10:34:42 UTC 2014


Hi Jon!

Please see comments inline
On 31.10.2014 7:45, Jon Masamitsu wrote:
> Evgeniya,
>
> I've only look at a few of the files.  I'm not sure
> I'm interpreting the @requires correctly.  If you
> reply to these initial comments, that will help
> me understand.
>
> http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/test/gc/arguments/TestMaxNewSize.java.udiff.html
>
> + * @requires vm.gc=="null"
> Test seems to expect Serial GC.  Should the requires
> be Serial or null?
The diff info is not full:
   25  * @test TestMaxNewSize
   26  * @key gc
   27  * @bug 7057939
   28  * @requires vm.gc=="null"
   29  * @summary Make sure that MaxNewSize always has a useful value 
after argument
   30  * processing.
   31  * @library /testlibrary
   32  * @build TestMaxNewSize
   33  * @run main TestMaxNewSize -XX:+UseSerialGC
   34  * @run main TestMaxNewSize -XX:+UseParallelGC
   35  * @run main TestMaxNewSize -XX:+UseConcMarkSweepGC
   36  * @run main TestMaxNewSize -XX:+UseG1GC

So test run with all GCs.

>
> http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/test/gc/arguments/TestSerialHeapSizeFlags.java.udiff.html
>
> Comments say this is a test of Serial but null
> allowed.
>
> + * @requires vm.gc=="Serial" | vm.gc=="null"
>
Test itself set "-XX:+UseSerialGC" flag and launch separate java process.
Setting @requires in such cases aiming 2 targets:
1)It is skipps if GC is for example ParallelGC. In concrete case you 
could guess it only for serial GC, but in some tests you couldn't.
So you see test passed and think it passed with your options and 
actually it passed with other GC. With requires you are totally sure 
test run with option you set. I believe such tests should be changed to 
pass options to the java processes, but now they doesn't.
2)From the other hand, when run without options, tests always run (ALL 
tests will run, no tests skipped at all)

> http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java.udiff.html
>
> If you're going to use this on all the collectors (allow vm.gc == null),
> then class loading should be turned off on all the GC's, not
> just CMS (-XX:-CMSClassUnloadingEnabled only affects CMS).
See previous comment. All tests you mentioned were not failed, and 
"requires" added for them to make order in test run.
>
> Jon
>
> On 10/30/2014 07:05 AM, Evgeniya Stepanova wrote:
>> Hi,
>>
>> Please review changes for 8062537, the OpenJDK/hotspot part of the 
>> JDK-8019361 <https://bugs.openjdk.java.net/browse/JDK-8019361>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8062537
>> fix: http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/
>>
>> Problem: Some tests explicitly set GC and fail when jtreg set another GC.
>> Solution: Such tests marked with the jtreg tag "requires" to skip 
>> test if there is a conflict
>>
>> Tested locally with different GC flags (-XX:+UseG1GC, 
>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and 
>> without any GC flag). Tests are being excluded as expected. No tests 
>> failed because of the conflict.
>>
>> Thanks,
>> Evgeniya Stepanova
>>
>

-- 
/Evgeniya Stepanova/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20141031/60ea1a5f/attachment.htm>


More information about the hotspot-gc-dev mailing list