RFR: 8199925: Break out GC selection logic from GCArguments to GCSelector

Per Liden per.liden at oracle.com
Mon Mar 26 06:33:00 UTC 2018


Hi Kim,

On 03/23/2018 09:13 PM, Kim Barrett wrote:
>> On Mar 21, 2018, at 9:11 AM, Per Liden <per.liden at oracle.com> wrote:
>>
>> Hi,
>>
>> Here's an updated webrev. I renamed GCSelector to GCConfig and it's now also the goto place for getting hold of the GCArguments instance for the currently selected GC.
>>
>> http://cr.openjdk.java.net/~pliden/8199925/webrev.1
>>
>> Btw, this is built on top of JDK-8199850 (Move parsing of VerifyGCType to G1) and JDK-8199918 (Shorten names of CollectedHeap::Name members), and the GCConfig::is_gc_* functions will eventually be used by JDK-8199927 (Make WhiteBox more GC agnostic).
> 
> I like this change, but don't have time right now to review it in detail, so don’t count me as a reviewer.
> 
> I do have a question though.  Why are there a bunch of private static members in GCConfig, rather
> just some more file-scoped statics in gcConfig.cpp?

I tend to prefer this approach for a few of reasons. First and maybe 
foremost, they get nicely name spaced. Being private members also makes 
it clear that they are part of this class' internal logic, and are not 
intended to be used by other classes. These functions also have public 
"siblings", in the form of the other is_gc_*, so I think it makes sense 
to group them in the same class.

/Per



More information about the hotspot-gc-dev mailing list