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

Kim Barrett kim.barrett at oracle.com
Fri Sep 25 18:47:46 UTC 2015

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.

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

More information about the hotspot-dev mailing list