[9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing

[Roland Westrelin]

>>> That one is not correct:
>>> 461   product(intx, MaxNodeLimit, 80000,                                        \
>>> 462           "Maximum number of nodes")                                        \
>>> 463           range(1000, 80000)                                                \
>>> 
>>> I think the upper bound should be max_juint
>> 
>> You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer.
>> 
>> Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users
>> 
>> C->set_max_node_limit(3*MaxNodeLimit);
>> 
>> If MaxNodeLimit == max_jint, this expression will overflow, I think.
> 
> Shouldn’t ranges in the flags definition check for reasonable values and then code like the 3*MaxNodeLimit above or the 80% of LiveNodeCountInliningCutoff below be robust to overflow? When someone changes the 3*MaxNodeLimit to 4*MaxNodeLimit, I doubt he’ll think he needs to update the flag definition: because it’s in a completely different location and because it doesn’t feel logical (at least, not to me).

For the record, I discussed this privately with Zoltán and he convinced me that going over every flags and making sure they don’t overflow where they are used is an unreasonable amount of work.

This change looks good to me.

Roland.