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

Jesper Wilhelmsson jesper.wilhelmsson at oracle.com
Wed Apr 29 20:38:17 UTC 2015


There are tests like hotspot/test/gc/g1/TestShrinkAuxiliaryData**.java where 
there is a base class that provides the test and a bunch of test classes that 
only starts the base test with different arguments. This case would be similar 
but slightly more ugly since the actual code would be the same and trigger the 
same base test, but with different @requires in the comment above the test.

I'm not sure it would help though. What we really would need here is a @requires 
that could check the host name or the hardware platform or OS.


Kim Barrett skrev den 29/4/15 20:35:
> On Apr 29, 2015, at 2:06 PM, Derek White <derek.white at oracle.com> wrote:
>> 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.
> That’s one solution.  A different solution would be to clone into multiple tests, one for each relevant collector, where the vm.gc can be “null” or the corresponding collector.  That cloning is kind of ugly though; it’s too bad there can only be one @requires constraint per test, rather than per @run line or the like.  But we didn’t get any traction with such a suggestion: https://bugs.openjdk.java.net/browse/CODETOOLS-7901090.
>> 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.
> I’m not sure how to address this problem.  For example, we don’t want to exclude TestSmallHeap.java on embedded JVMs, we just want to exclude its sub-cases that would attempt to use a gc that isn’t supported.

More information about the hotspot-gc-dev mailing list