RFR (XS): 8078673: Update TEST.groups for recent GC tests

Derek White derek.white at oracle.com
Wed Apr 29 18:06:19 UTC 2015


On 4/29/15 1:14 PM, Dmitry Fazunenko wrote:
> Derek,
>
> @requires is a quite new feature of jtreg. It's used in the cases when 
> a test should  not be executed in certain circumstances.
> The most typical use case if a test runs VM with a one GC, and another 
> GC is specified on the command line.
>
> On 29.04.2015 19:58, Derek White wrote:
>> Hi Dima,
>>
>> Thanks for the info. I looked briefly at using @requires but couldn't 
>> quite make sense of it. I definitely prefer have all of the info in 
>> the test, rather than modifying some random file elsewhere.
>>
>> So I understand at requires vm.gc=="null" means require all collectors 
>> to be implemented.
> It means, that the test uses all collectors, and if a collector is 
> specified on command line the test (one of its @run) will fail with
> Example: gc/TestSmallHeap.java
>>
>> What does @requires vm.gc == "G1" | vm.gc == null" mean?
> It means that test should work if either G1 is given on command line 
> (-vmoptions:-XX:+UseG1GC) or no collector specified.

OK, this is getting interesting.

So most of these tests use ProcessBuilder to specify a command line, and 
explicitly mention a GC to use. A single test might actually run each 
collector (gc/logging/TestGCId, for example). Does @requires matter in 
this case?

Oh, maybe they should all have @requires vm.gc=="null", becuase the 
actual test is ignoring GC passed in by the test harness GC and running 
as a separate process anyway. It's misleading if the harness said 
UseG1GC and the test was actually running UseParallelGC, for example.

FYI, it sounds like my original problem does require the exclude lists 
to keep the embedded JVM from running GC tests that it shouldn't.

  - Derek
>> Is this documented somewhere?
>
> It's documented in jtreg:
> http://jre.us.oracle.com/java/re/jtreg/4.1/promoted/latest/binaries/jtreg/doc/jtreg/tag-spec.html
>
> Thanks,
> Dima
>
>
>>
>> Thanks!
>>
>>  - Derek
>>
>> p.s. It turns out that TestDynamicNumberOfGCThreads and TestSmallHeap 
>> use @requires vm.gc=="null".
>
>
>
>>
>> On 4/29/15 12:25 PM, Dmitry Fazunenko wrote:
>>> Hi Derek,
>>>
>>> Sorry for the late comment.
>>>
>>> Adding needs_XXXgc groups was a temporary solution for the period 
>>> when jtreg didn't support @requires.
>>> Those groups are not used anymore in our nightly runs and will be 
>>> removed soon.
>>>
>>> The more proper way to specify that a test is not applicable for a 
>>> certain collector is adding @requires tag.
>>> Like:
>>> * @requires vm.gc == "G1" | vm.gc == null
>>> or
>>> if a test use all collectors:
>>>  * @requires vm.gc=="null"
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 29.04.2015 18:00, Derek White wrote:
>>>> Thanks Eric!
>>>>
>>>> On 4/29/15 10:44 AM, Eric Caspole wrote:
>>>>> Hi Derek,
>>>>> Looks good to me.
>>>>> And now I learned how TEST.groups works ;)
>>>>> Eric
>>>>>
>>>>>
>>>>> On 4/28/2015 5:31 PM, Derek White wrote:
>>>>>> Please review this simple for GC tests that require certain 
>>>>>> collectors (e.g. shouldn't run in embedded).
>>>>>>
>>>>>> Certain GC regression tests require specific collectors to be 
>>>>>> enabled in the JVM (by using -XX:+UseParallelGC, etc). But these 
>>>>>> tests were not listed in TEST.groups.
>>>>>>
>>>>>> This webrev adds the following tests to the appropriate 
>>>>>> needs_g1gc, needs_serialgc, needs_parallelgc, and needs_cmsgc lists.
>>>>>>
>>>>>>   * gc/TestSmallHeap.java
>>>>>>   * gc/TestCardTablePageCommits.java
>>>>>>   * gc/arguments/TestParallelHeapSizeFlags.java
>>>>>>     gc/ergonomics/TestDynamicNumberOfGCThreads.java
>>>>>>   * gc/logging/TestGCId.java
>>>>>>
>>>>>> CR:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8078673
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~drwhite/8078673/webrev.00/
>>>>>>
>>>>>> Testing:
>>>>>> JPRT
>>>>>>
>>>>>> Thanks,
>>>>>>  - Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20150429/7ec6cb9c/attachment.html>


More information about the hotspot-gc-dev mailing list