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

[David Holmes]

On 11/03/2020 12:51 am, Magnus Ihse Bursie wrote:
> On 2020-03-09 10:10, David Holmes wrote:
>> Hi Magnus,
>>
>> 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.
> While I agree that it is not very much important per se to build Hotspot 
> without the Serial GC, I do want to make sure that we uphold the promise 
> that configure fails early if you try to build with invalid options.
> 
> So it's either not allowing configure to let you to build without the 
> Serial GC, or it's fixing Hotspot so that it can build without it. My 
> judgement was that the fixes required to make this work was minimal, 
> without any impact to scenarios that *do* include Serial GC, and thus it 
> was "worthwile" to fix this in Hotspot, rather than to make a limitation 
> in the configure script.

I'm more inclined to say that SerialGC is not a VM feature per-se but 
rather an always present built-in GC. But I'll leave that to the GC folk.

>>> With this patch it is possible to build a truly minimal JVM using 
>>> 'configure --with-jvm-variants=custom --with-jvm-features=g1gc'.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240224
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8240224-building-without-serial-gc/webrev.01 
>>
>>
>> make/ModuleTools.gmk
>>
>> ! TOOL_ADD_PACKAGES_ATTRIBUTE := $(BUILD_JAVA) 
>> $(JAVA_FLAGS_SMALL_BUILDJDK) \
>>
>> that should be BUILDJDK_JAVA_FLAGS_SMALL.
> Good catch! I renamed this at the very last moment, but missed this. :-(
> 
>>
>>
>> make/RunTestsPrebuiltSpec.gmk
>> make/autoconf/boot-jdk.m4
>>
>> ! BUILDJDK_JAVA_FLAGS_SMALL := -Xms32M -Xmx512M -XX:TieredStopAtLevel=1
>>
>> Depending on the default GC those -Xms and -Xmx settings may not be 
>> valid/possible.
> Eh, okaaaay, this is not really something new, we're already setting 
> this for the buildjdk. The only difference is that we mis-used the 
> JAVA_FLAGS_SMALL variable, that was technically only valid for the 
> bootjdk. So we have not seen any issues with this in practice. I'm still 
> a bit worried though that you say that this might not work. How can the 
> -Xms/mx values be invalid?

Previously these heap sizes were associated with use of SerialGC:

! JAVA_FLAGS_SMALL := -XX:+UseSerialGC -Xms32M -Xmx512M 
-XX:TieredStopAtLevel=1
! BUILDJDK_JAVA_FLAGS_SMALL := -Xms32M -Xmx512M -XX:TieredStopAtLevel=1

now you are setting them independent of a particular GC. It may be 
possible that with some GC's the specified heap size is not sufficient 
to allow the build task to complete without getting an OutOfMemoryError. 
As an extreme case consider if you only have EpsilonGC configured. These 
values would need to be tested with each GC to see if the build tasks 
can be done with these settings.

Also I'm not at all clear what happens if the only GC configured is one 
of the experimental GCs for which we would normally have to set 
-XX:+UnlockExperimentalVMOptions ??

Cheers,
David
-----

>>
>> Other changes seem okay but I'll leave it for GC folk to comment on that.
> Thanks for the review!
> 
> /Magnus
>>
>> Cheers,
>> David
>>
>>
>>>
>>> /Magnus
>