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