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

Jon Masamitsu 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, (maxjint-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

More information about the hotspot-dev mailing list