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

[Jon Masamitsu]

On 9/25/2015 11:47 AM, Kim Barrett wrote:
> On Sep 24, 2015, at 6:16 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>> But I think the test programs that check the ranges are
>> generated by looking at lines in the source such as 243
>>
>> 243           range(0, (max_jint-1)/4)
> The particularly interesting test right now is TestOptionsWithRanges, which looks at
> the recorded range bounds in the VM running the test, and launches a new VM with
> option values based on those discovered range values.
>
>> If the line had some call to a function to get the number of hardware
>> threads I could see things going wrong
>>     - Maybe generation of tests is not on the same machine as run the tests and
>> range is set at the time the test is generated
> Yes, this situation would break TestOptionsWithRanges as presently written.  We don’t
> presently do anything like that though, that I know of.

OK.  I won't be concerned about that.
>
>>     - Maybe the determination of the number of hardware threads is not reliable
> We have lots of code that uses that number, so such a problem would be a significant bug.

Yes, lots of policy depends on the number but I don't think any of it 
would break
if the number is different run to run.   And the small integer 
multiplier will hide
any of that variation.

>
>>     - Maybe code gets moved around so that the number of hardware threads
>> are not available when argument parsing is done
> We use the number of hardware threads in the ergonomic setting of a number of options.

Ergonomics sets options non-optimally but don't fail in a way that is 
easily noticed.

>
>> Something simple like a really big number trimmed back some still
>> appeals to me.
> My issue with that is that we then need to disable the associated option test, and we may need
> to make the code that uses the option be defensive against wacky values that we’d rather have
> filtered out by argument parsing.  I realize that’s a complex problem though, and not always
> amenable to a good solution.  And in this case the code using the option likely still needs to be
> defensive, since even a “reasonable” value might exhaust available resources.

My problem is that what seems "wacky" to everyone may not in the end
be "wacky".

>
> If the using code needs to be defensive anyway, then I don’t see the point in having some more
> or less randomly chosen upper bound for argument checking.  And we don’t need a lower bound
> check since the type of the option is unsigned.

I agree with this as long as anything that is specified on the command line
for ParallelGCThreads will fit into a uint.   After some reality checks
here I think removing the range check in favor of a constraint function
where we could add more defensive checks would be an improvement.

Jon

>