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

[Roland Westrelin]

Hi Zoltan,

>> 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).

> So I set the limit to (max_jint / 3) in the updated webrev.
> 
> If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort.
> 
>>  699   product(intx, LiveNodeCountInliningCutoff, 40000,                         \
>>  700           "max number of live nodes in a method")                           \
>>  701           range(0, max_juint / 8)                                           \
>> 
>> Out of curiosity why max_juint / 8 (not that it makes much of a difference)?
> 
> In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way:
> 
> if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) {
> 
> If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8.

>> 2877   product(intx, TypeProfileArgsLimit,     2,                                \
>> 2878           "max number of call arguments to consider for type profiling")    \
>> 2879           range(0, 16)                                                      \
>> 
>> 2880                                                                             \
>> 2881   product(intx, TypeProfileParmsLimit,    2,                                \
>> 2882           "max number of incoming parameters to consider for type profiling"\
>> 2883           ", -1 for all")                                                   \
>> 2884           range(-1, 64)
>> 
>> Why 16 and 64?
> 
> These are the largest values that work on all platforms we support.

Sorry, I still don’t understand that. Based on implementation details?

Roland.