Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests

[Dmitry Fazunenko]

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:
>>>>
>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/
>>>
>>> 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:
>
> https://bugs.openjdk.java.net/browse/CODETOOLS-7901091

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

-- Thanks,
Dima

>
> Bengt
>
>>
>>>
>>> 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.
>>
>> Thanks,
>> Dima
>>
>>
>>>
>>> thanks
>>> Mandy
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20141111/af4912b8/attachment.html>