RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing
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:
>>> 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.
> 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