RFR 8078555(M): GC: implement ranges (optionally constraints) for those flags that have them missing

[sangheon.kim]

Hi Derek,

Thank you for the kind explanation!
For me adding these tags would be better as these will reduce testing time.

Kim, may I ask your opinion?

Thanks,
Sangheon


On 08/28/2015 01:41 PM, Derek White wrote:
> Hi Sangheon, Kim,
>
> On 8/28/15 1:27 PM, sangheon.kim wrote:
>> Hi Kim,
>>
>> On 08/28/2015 09:50 AM, Kim Barrett wrote:
>>> On Aug 28, 2015, at 2:44 AM, sangheon.kim <sangheon.kim at oracle.com> 
>>> wrote:
>>>
>>>> 1. @requires vm.gc==xx for 4 test cases. (Derek)
>>> Is this actually needed?  I'm not sure how the process builder works.
>>> Does it use any options from the calling process?
> This is an FYI - not a stopper.
>
> The main issue is that there's a disconnect between the jtreg 
> framework, including the @requires mechanism, and most tests that use 
> ProcessTools.
>
> Adding "@requires vm.gc=" doesn't totally fix the problem, but it ties 
> the two together. If you don't do @requires, then this situation can 
> happen:
>
> Due to jtreg argument roulette in nightlies, jtreg will run 
> TestObjectTenuringFlags (which is a parallel-only test), while perhaps 
> specifying |-XX:+UseG1GC and/or ||-||/XX/:+UseConcMarkSweepGC|to the 
> outer level test. But there's no point running the outer test 
> framework four ways (default, g1, cms, and parallel) when the real 
> inner test always gets run with parallel GC. You just ran the same 
> test 4 times. This is not directly harmful, but it's unnecessary and 
> makes jtreg nightly runs longer.
>
> It's also indirectly harmful because when a failure occurs it's very 
> easy for bug triage or the initial bug handler to get confused and 
> think it's a G1 or CMS bug (because that's at the top-level of the 
> error report says). Yes, this has happened to me!
>
>> If you are asking about any options are passed via @run tag, NO these 
>> 4 tests don't use them.
>> e.g.
>> @run main/othervm -XX:xxxxx
>>
>> I added them as ProcessTools.createJavaProcessBuilder() takes 
>> specific GC mode options.
>> Maybe I am misunderstanding the tag.
>>
>> Anyone can give clear advice for this? Derek?
>>
>>>    If not, then I
>>> don't think these new @requires are needed.
>>>
>>> Hm, I see lots of G1 tests that use the process builder and don't have
>>> @requires lines, which argues this block of changes is not needed.
>> Right.
> And if all the other tests jumped off a bridge would you do it too? 
> :-) In short, I don't think the change is strictly necessary, but I 
> think it's a good idea that we should start using in all of our 
> GC-specific tests that go through ProcessTools.
>
> I'm fine with or without this change. Maybe I should bring it up in 
> the SQE talk at the offsite to get consensus.
>
>  - Derek