On Wed, 6 May 2026 11:26:16 GMT, Aleksey Shipilev <[email protected]> wrote:
>> make/autoconf/boot-jdk.m4 line 485: >> >>> 483: >>> 484: # Use serial gc for small short lived tools if possible >>> 485: >>> UTIL_ADD_JVM_GC_ARG_IF_OK([-XX:+UseSerialGC],boot_jdk_jvmargs_small,[$JAVA],[serialgc]) >> >> Something is off here. This builds up `boot_jdk_jvmargs`, which has no >> relationship to the JVM feature flags enabled currently in the build. That >> is, if you have a boot JDK that does not carry Serial, it would still fail. >> >> There is a block below, saying: >> >> >> # Don't presuppose SerialGC is present in the buildjdk. Also, we cannot >> test >> # the buildjdk, but on the other hand we know what it will support. >> >> >> Which seems to say that we just "know" Serial would be there. But that is a >> flimsy precondition. So maybe we should "just" stop opting into Serial GC >> everywhere, and rely on default collector choice. > > _Actually_, I believe not using Serial for small tools is completely in line > with the intent of JEP 523, so it would be a proverbial dog-fooding to rely > on G1 for small tools. If G1 is significantly slower in scenario where Serial > used to be a better choice, OpenJDK developers should be the first to suffer > :) In my somewhat limited local tests (for jep 523), the difference of using g1 for everything is <1% non-significant for a full slowdebug rebuild (in all metrics, i.e. user/sys/cpu/total time, 5 runs, alpha=0.05), i.e. a `make images`. I am fine with just removing the -XX:+SerialGC optimization. I did notice that comment, and agree with you, but did not want to do extensive build perf testing. See also https://bugs.openjdk.org/browse/JDK-8359802?focusedId=14802646&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14802646 on a different machine. If nobody objects I'll remove this optimization after some more testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31049#discussion_r3195311108
