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

[Erik Joelsson]

On 2020-03-09 02:20, Aleksey Shipilev wrote:
> On 3/9/20 10:10 AM, David Holmes wrote:
>> On 9/03/2020 6:30 pm, Magnus Ihse Bursie wrote:
>>> When reworking the JVM feature handling, I wanted to try to compile
>>> Hotspot with various features enabled/disabled. I quickly found out that
>>> it's not really possible to build hotspot without the serial gc. While
>>> this is not a terribly important use case, I think it's good to be able
>>> to select serial freely, just as with the other collectors.
>> Really not sure this is a worthwhile exercise.
> Me neither. I think Serial GC always-present is a good compromise for the rest of the code: it is
> the very basic GC you can always count on.
I'm not a GC developer, but from a build point of view, it makes sense 
to allow for as free modularity of JVM features as possible. Certainly 
not all combinations are a good idea, and we are most definitely not 
going to test all combinations, but I also don't think the build should 
actively prevent anyone from experimentally exclude certain "features". 
I would imagine this kind of freedom being useful in certain development 
scenarios.
> 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.

/Erik

> *) hotspot/gtest/gc/shared/test_collectorPolicy.cpp
>   - I don't think we indent nested #include, #define lines
>