> On Mar 10, 2020, at 10:51 AM, Magnus Ihse Bursie > <[email protected]> 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.
