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
