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
