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

Roman Kennke rkennke at redhat.com
Wed Mar 21 09:15:00 UTC 2018


Am 21.03.2018 um 09:12 schrieb Per Liden:
> In an attempt to make WhiteBox more GC agnostic, and in turn make it
> easier to plugin new GC without touching a lot of non-GC code, this
> patch breaks out the GC selection logic from GCArguments to GCSelector.
> There are two reasons why I think this makes sense:
> 1) The GC selection logic is self-contained and fairly unrelated to the
> rest of the flags processing done by GCArguments and its GC-specific
> children.
> 2) Parts of the GC selection logic is needed by WhiteBox to answer
> questions about which GC are supported, selected, etc.
> 
> A follow up patch (JDK-8199927) will change WhiteBox (WB_CurrentGC,
> WB_AllSupportedGC, WB_GCSelectedByErgo), to use the GCSelector.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199925
> Webrev: http://cr.openjdk.java.net/~pliden/8199925/webrev.0
> 
> /Per

My original proposal for the GCArguments did have a separate GCFactory. :-)

In generally I like your change.

I'd probably go even further and let GCSelector initialize and return an
instance of GCArguments. This way we wouldn't end up with two places
that have knowledge of all possible GCs, but would only have one place
(GCSelector) where one had to hook up for adding a new GC.

What do you think?

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180321/1e7a4ed3/signature.asc>


More information about the hotspot-gc-dev mailing list