Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests
Dmitry.Fazunenko at oracle.com
Mon Nov 10 21:14:59 UTC 2014
On 10.11.2014 20:28, Bengt Rutisson wrote:
> On 2014-11-08 09:11, Dmitry Fazunenko wrote:
>> Hi Mandy,
>> On 08.11.2014 02:41, Mandy Chung wrote:
>>> On 11/7/14 3:34 AM, Evgeniya Stepanova wrote:
>>> What are the valid values ofvm.gc? It's a bit awk for null as a
>>> valid value and I would imagine "*" wildcard may be a better value?
>> vm.gc variable is set by jtreg based on passed -XX:+Use???GC command
>> line vm flag.
>> If such flag is not given vm.gc will be set to null (or "null" which
>> is same).
>> So, vm.gc could be set to any value. In reality the following strings
>> are expected: null, "Parallel", "Serial", "G1", "ConcMarkSweep".
>> null means "not set", it doesn't mean "any".
>> If a test is applicable for all GC - you don't need @requires vm.gc
>> == "*"
> Note that the vm.gc abstraction is not really flexible enough for our
> purposes. The way to specify a GC is constantly evolving and it is not
> suitable to have this logic in the JTreg harness. I've filed this bug
> about the issue:
You're absolutely right! @requires vm.gc has limited use.
Using VM specific class to decide if a test applicable or not will be
much more flexible for us.
I'm not sure that this approach is applicable for jtreg... But let's see
>>> Since you are touching test/java/lang/management/** tests, we can
>>> remove these shell tests and add multiple @run in the java test
>>> instead. It'd be great if you can take this opportunity to remove
>>> these shell tests as they are not really necessary.
>> Yes, agree, shell is not necessary here. But such refactoring is
>> better to be done as part of another RFE.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev