RFR: JDK-8240224 Allow building hotspot without the serial gc

[Kim Barrett]

> On Mar 10, 2020, at 10:51 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>> Nits:
>>> 
>>> *) src/hotspot/share/gc/shared/gcConfig.cpp changes are a bit strange:
>>>   - Epsilon should not ever be selected by ergonomics
>>>   - Why ZGC is selected before Shenandoah? [Oh, what a can of worms that one is ;)]
>> 
>> This fallback list is clearly just meant to allow for any combination of GCs being compiled into the JVM. If the only one you picked was epsilon, then what other default would you expect? It's last in the list so any other GC will still be prioritized before it if present. For the same reason, the order of ZGC and Shenandoah is irrelevant and could just as well be the other way. It will never have any real consequence. This code is only there to keep things from falling apart when a non standard combination of jvm features is picked.
> Exactly. For good measure, I can surely put Shenandoah before ZGC. :)

Whichever one is placed first will likely annoy the folks behind the competing second.  There’s
no way to win this one.

> The idea behind the added defaults as fallback is just to allow the JVM to even start if Serial GC is not present. If you configure with SerialGC (which, as you note, is the typical case), this change will not affect anything. Without this, it is not even possible to complete the build without SerialGC, since jlink cannot run.

The is_server_class_machine() test is intended to filter out collectors that (probably)
don’t make sense to run on “small” machines.  (Admittedly, it’s not so easy to buy a
computer that doesn’t qualify for is_server_class_machine() anymore, outside of the
embedded space, and even there…)  But we let one insist by allowing the default to
be overridden by an explicit selection.