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

[Jon Masamitsu]

On 09/23/2015 01:00 PM, Kim Barrett wrote:
> On Sep 22, 2015, at 7:04 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>>>> src/share/vm/gc/g1/g1_globals.hpp
>>>>   240   product(uintx, G1ConcRefinementThreads, 0,                                \
>>>> ...
>>>>   243           range(0, (max_jint-1)/4)                                          \
>>>>
>>>> I know we discussed the problem of thread counts.  I'd suggested
>>>> perhaps basing the upper bound on the number of processors. (Some
>>>> care might be needed for uniprocessor systems.) I couldn't find any
>>>> followup on that suggestion though.
>> Kim,
>>
>> My apologies but I dissuaded Sangheon from that idea.   I don't think the
>> number of processors was enough.  A hundred or a thousand times the
>> number of processors should be enough but if I had to pick some
>> multiplier like that, I'd rather pick something limited by the size
>> of the type and back off some.   It's still arbitrary but whereas I might
>> some decade be surprised that 1000 * #-of-processors was too few,
>> I'm not going to see 1,000,000,000 be too few.
> I suspect we're using different meanings for "processor".  I meant
> "number of processing units", e.g. the number of lines in Linux
> /proc/cpuinfo that begin with the word "processor".  A more precise
> term might be "hardware concurrency".  A maximum multiplier of 1-2
> seems to me sufficient for these generally CPU-intensive tasks.243           range(0, (max_jint-1)/4)
>

I try to use the term "hardware threads" which I think matches
your definition and I agree that I've never seen a case where a
small integer * #of hardware threads was not a reasonable limit.
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)

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
     - Maybe the determination of the number of hardware threads is not 
reliable
     - Maybe code gets moved around so that the number of hardware threads
are not available when argument parsing is done

Something simple like a really big number trimmed back some still
appeals to me.

Jon