On 2020-03-09 16:28, Erik Joelsson wrote:
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.
Yes, that's exactly the intention.
And on the contrary, if the discussion on this patch ends up in the
verdict from the hotspot developers that it is not possible to disable
serialgc, then the configure script should reflect that, and disallow
deselecting it. In fact, it should not really even be a "JVM feature"
then, just an always-on GC. And the check that Stefan Karlsson added,
that at least one GC is selected, is unnecessary.
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. :)
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.
/Magnus
/Erik
*) hotspot/gtest/gc/shared/test_collectorPolicy.cpp
- I don't think we indent nested #include, #define lines
Ok, sorry about that. That was the style of choice last time I
programmed something seriously in C, so I just defaulted to it. I'll fix it.
/Magnus
