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

[sangheon.kim]

Hi Kim,

On 08/31/2015 11:05 AM, Kim Barrett wrote:
> On Aug 28, 2015, at 4:41 PM, Derek White <derek.white at oracle.com> wrote:
>> 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.
> Derek - thanks for the explanation.
>
> Given how intermittent some of our bugs can be, this might not even be
> strictly harmful.  But I see your point.
>
>> 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!
> Ouch!  Yes, that's a good argument for this kind of change.
>
>> 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.
> Looks like you added this issue to the offsite agenda.
>
> I have a mild preference for removing this part of the changes, to be
> consistent with what seems to be the status quo.  (But note that there
> are a few existing counterexamples.)  That preference is not so strong
> that I would object to going ahead with the changes as is.  I'll leave
> it up to Sangheon, and I don't need a new webrev if he backs out the
> new @requires.
Let me include @requires.

Thanks,
Sangheon


>
> Looks good.
>