RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing (original) (raw)
Kim Barrett kim.barrett at oracle.com
Fri Sep 25 18:47:46 UTC 2015
- Previous message: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing
- Next message: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- 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.
- 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.
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.
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.
- Previous message: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing
- Next message: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]