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

[Magnus Ihse Bursie]

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