RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing (original) (raw)
Jon Masamitsu jon.masamitsu at oracle.com
Thu Sep 24 22:16:04 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 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/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.243 range(0, (maxjint-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
- 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 ]