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
Wed Sep 23 20:00:42 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 22, 2015, at 7:04 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
src/share/vm/gc/g1/g1globals.hpp _240 product(uintx, G1ConcRefinementThreads, 0, _ ... _243 range(0, (maxjint-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.
- 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 ]