RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing
jon.masamitsu at oracle.com
Fri Sep 25 22:57:22 UTC 2015
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
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
>> 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
> 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.
More information about the hotspot-dev