RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing

[sangheon.kim]

On 10/05/2015 02:06 PM, Kim Barrett wrote:
> On Oct 5, 2015, at 4:35 PM, sangheon.kim <sangheon.kim at oracle.com> wrote:
>> On 10/05/2015 11:31 AM, Kim Barrett wrote:
>>>> I can revert to webrev.02 and change groups to AfterMemoryInit.
>>> I would prefer that.
>> Okay, I will revert to webrev.02 and change the group to AfterMemoryInit.
> Thanks.
>
>>>>> But this discussion is making me question all of the FLAG_IS_xxx uses
>>>>> in commandLineFlagConstraintsGC.cpp.
>>>> For some options, they are automatically added to validate.
>>>> (e.g. SurvivorRatio for CMS GC )
>>>> So FLAG_IS_xxx is needed for some cases.
>>> The (pre-existing) ergonomics around SurvivorRatio seem quite strange
>>> to me.  Why is the behavior be different when the value is defaulted
>>> vs when it is explicitly specified with the same value as the default?
>> SurvivorRatio is a little bit special as it will be automatically validated and its default value is 8.
>> And this behavior would make hard to constraint function to decide.
>> For example, when we set 4m of heap for G1, the SurvivorRatio is 8 but we have only 4 regions from default setting.
>> In this case, without FLAG_IS_xxx it is hard to decide whether the result is FAIL or SUCCESS.
>> And I think it is okay in this case.
>> This is why explicitly specified option is only validated.
> So the “default" value isn’t *really* the default, but more of a suggested value to use
> if it would work and is not overridden from the command line.  Specifying the purported
> default value explicitly and getting different behavior would, for me, violate the principal
> of least surprise.
Yes, it is strange.

>   The present implementation also violates the “rule” that when there is
> a default that can be overridden, there should always be a way to explicitly request the
> default.
If you are talking about we should have a way to get the default value 
of an option(even though the option's value is changed, need a way to 
get the previous default value), yes it would be nice to have.

>   But none of this really has anything to do with 8134995.
>
>>> I don't expect anything to be done about this right now, but I think
>>> this does help make the case for using FLAG_IS_CMDLINE in the pause
>>> time options under discussion.
> Drat.  I meant “… this does *not* help make the case …”
:)

>
>> I agreed to revert to webrev.02 + changing group.
>> What is next? :)
> Nothing that I know of.  I think you’re good to go.
Okay, thanks!

Here's next webrev:
http://cr.openjdk.java.net/~sangheki/8134995/webrev.04
http://cr.openjdk.java.net/~sangheki/8134995/webrev.04_to_03

Thanks,
Sangheon
>