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

Kim Barrett kim.barrett at oracle.com
Wed Sep 23 20:00:42 UTC 2015

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.

More information about the hotspot-dev mailing list