RFR(XXS): 8006894: G1: Number of marking threads missing from PrintFlagsFinal output
john.cuthbertson at oracle.com
Fri Jan 25 00:08:34 UTC 2013
Thanks for the review. I'll make the change you suggested.
I was originally toying with adding an assert:
assert(FLAG_IS_CMDLINE(...), "..") to capture that a non-zero value had
to have been set by the user but decided against it.
On 1/24/2013 3:45 PM, Jon Masamitsu wrote:
> Change looks good.
> It wasn't obvious to me that the default for ConcGCThreads is 0 so
> I had to look at the "if (ConcGCThreads > 0)" a couple of times
> before I understood that it was really
> "if (ConcGCThreads-is-user-specified-and-greater-than-0)"
> Would you consider changing to
> if (!FLAG_IS_DEFAULT(ConcGCThreads) && ConcGCThreads > 0)
> It's more wordy and doesn't really change anything but I think
> it's more readable.
> On 1/24/2013 3:01 PM, John Cuthbertson wrote:
>> Hi All,
>> Can I have a couple of volunteers look over this small change? The
>> webrev can be found at:
>> When G1 calculates the number of marking threads based upon (the
>> develop-only) G1MarkingOverheadPercent or (more usually)
>> ParallelGCThreads, we weren't setting the value of ConcGCThreads. As
>> a result the output of PrintFlagsFinal would always show a zero if
>> ConcGCThreads wasn't specified on the command line:
>> uintx ConcGCThreads = 0
>> This made it difficult for the performance team to analyze marking
>> behavior and offer advice. With this change we now get the calculated
>> number of marking threads:
>> Using ParallelGCThreads (default: 4):
>> uintx ConcGCThreads := 1
>> Using G1MarkingOverheadPercent (50):
>> uintx ConcGCThreads := 2
>> Command line testing; specjvm98 and dacapo with a low IHOP value
>> (marking threshold).
More information about the hotspot-gc-dev