On Thu, 7 May 2026 05:01:17 GMT, David Holmes <[email protected]> wrote:
>> If default GC choice and sizing is good enough, I'm all for dropping the >> explicit flags. Back when we set serialgc, I believe the difference was >> quite significant. If you can show that the difference is negligible, then >> please remove it. >> >> If the difference is still relevant, then the correct fix is to only modify >> the BUILD_JAVA flags, and then only if we are using the just built JDK as >> BUILD_JDK. Looking at the code, as Alexey pointed out, we aren't even >> setting serialgc in the BUILD_JAVA_FLAGS_SMALL. We are however setting >> JAVA_TOOL_FLAGS_SMALL based on JAVA_FLAGS_SMALL, and we then use >> JAVA_TOOL_FLAGS_SMALL with JMOD, which is run from the BUILD_JDK. That is a >> bug. We need a separate BUILD_JAVA_TOOL_FLAGS_SMALL. Is it the jmod command >> that failed when you disabled serialgc, or something else? > > I just want to state for the record (again) that despite the nice illusionary > picture painted by all the `#ifdef INCLUDE_XXX` in the code, it was never a > goal/expectation to be able to build OpenJDK with an arbitrary combination of > selected features. The selectivity arose from the requirement to have a > Minimal VM and Compact Profiles back in JDK 8. And of course as new GCs are > developed they get their own special include/exclude handling. In that regard > Serial GC is/was always expected to be present. Jmod and later some javap executions fail as they use the JAVA_TOOL_FLAGS_SMALL flags. I'll do some more testing with these flags removed, to me the perf difference is negligible (when we diagnosed/added these flags, iirc the diagnosed issue has been mostly VM startup where G1 has been much slower. This is not the case any more for a long time). If not I will introduce a separate BUILD_JAVA_TOOL_FLAGS_SMALL. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31049#discussion_r3199463059
