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

sangheon.kim sangheon.kim at oracle.com
Mon Oct 5 21:45:06 UTC 2015

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 FLAGISxxx uses in commandLineFlagConstraintsGC.cpp. For some options, they are automatically added to validate. (e.g. SurvivorRatio for CMS GC ) So FLAGISxxx 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 FLAGISxxx 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 FLAGISCMDLINE 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

More information about the hotspot-dev mailing list