RFR: 8199927: Make WhiteBox more GC agnostic
Per Liden
per.liden at oracle.com
Thu Mar 22 10:21:53 UTC 2018
On 03/22/2018 10:08 AM, Aleksey Shipilev wrote:
> On 03/22/2018 10:04 AM, Per Liden wrote:
>> On 03/21/2018 04:03 PM, Aleksey Shipilev wrote:
>>> This is a little dizzy, because I would have expected gc.isSelected() would tell me exactly what GC
>>> was being selected:
>>>
>>> isAcceptable = gc.isSupported() && (gc.isSelected() || GC.isSelectedErgonomically());
>>>
>>> ...so it should be just:
>>>
>>> for (GC gc : GC.values()) {
>>> map.put("vm.gc." + gc.name(), "" + gc.isSelected());
>>> }
>>>
>>
>> The way VMProps works and how the properties are set up can indeed make you a little dizzy. For
>> example, vm.gc.Parallel=true doesn't necessarily mean that ParallelGC was "selected", just that it's
>> an "acceptable" configuration.
>>
>> A test running with an explicit -XX:UseG1GC flag will get:
>> vm.gc.Serial=false
>> vm.gc.Parallel=false
>> vm.gc.CMS=false
>> vm.gc.G1=true
>>
>> And a test running with no explicit GC flag (which selects G1 ergonomically), will get:
>> vm.gc.Serial=true
>> vm.gc.Parallel=true
>> vm.gc.CMS=true
>> vm.gc.G1=true
>
> Ewww, messy. I naively thought vm.gc.* filters for jtregs are filtering based on what GC was
> actually running. But this is another thing to follow-up on. The patch itself looks good then.
To add to the confusion, there's also a vm.gc property, which only
reflects what was explicitly specified on the command line. I don't
quite see why it was done like this. I kind of hope we can clean that up
some day. A single vm.gc property should be enough as far as I can tell,
but maybe I'm missing something.
Anyways, thanks for reviewing!
/Per
>
> -Aleksey
>
More information about the hotspot-gc-dev
mailing list