8334617: -XX:+UseSerialGC sent to newly built JDK even if serialgc is disabled

[tschatzl]

Hi all,

please review this change that allows building of the JDK without Serial GC enabled.

There were some hardcoded entries for -XX:+UseSerialGC in the makefiles, and one of the gtests is serial gc specific and needed to be moved. Noticed during tests with JEP 523: Make G1 the Default Garbage Collector in All Environments.

I opted to a different fix than suggested in the CR, instead of wholesale ignoring unrecognized options, only add serial gc to the relevant options if the feature is enabled in the build. The change seems small enough.

Tested manually with and without --with-jvm-features=-serialgc, both image building and running the test works in both cases (being skipped/not found if serial gc has not been enabled).

Other testing: gha

Thanks,
Thomas

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

• JDK-8334617: -XX:+UseSerialGC sent to newly built JDK even if serialgc is disabled (Bug - P4)

Reviewers

• Axel Boldt-Christmas (@xmas92 - Reviewer) 🔄 Re-review required (review applies to 4a3a3c12)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/31049/head:pull/31049
$ git checkout pull/31049

Update a local copy of the PR:
$ git checkout pull/31049
$ git pull https://git.openjdk.org/jdk.git pull/31049/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 31049

View PR using the GUI difftool:
$ git pr show -t 31049

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/31049.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back tschatzl! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@tschatzl The following labels will be automatically applied to this pull request:

• build
• hotspot-gc

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[openjdk]

The total number of required reviews for this PR has been set to 2 based on the presence of this label: hotspot-gc. This can be overridden with the /reviewers command.

[shipilev]

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.

[shipilev]

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 :)

[tschatzl]

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.

[erikj79]

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?

[dholmes-ora]

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.

[tschatzl]

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.

[mlbridge]

Webrevs

• 02: Full - Incremental (b278aac8)
• 01: Full - Incremental (4a3a3c12)
• 00: Full (bbce89d5)

[tschatzl]

Test: fastdebug image building (that's what I mostly do, but ymmv)

Either using -XX:+UseG1GC wherever there is currently -XX:+UseSerialGC in the makefiles - this is the case after making G1 default always (JEP 523); without JEP 523 one would either get Serial by default (exactly the same as before) or G1, which I explicitly tested.

$ for i in seq 0 4; do make reconfigure clean CONF=fastdebug-test; /usr/bin/time -a -o baseline.time make CONF=fastdebug-test images ; done

• the build configurations may not have been completely comparable across platforms; basically using whatever was configured at the time. Mix of open only/including closed sources.
• note that depending OS, time output is different
• the systems were idle, but not particularly benchmark-prepared

aarch64/OSX Apple M4-something

With -XX:+UseG1GC
242,37 real 1027,29 user 328,87 sys
242,10 real 1041,49 user 327,30 sys
242,55 real 1041,00 user 327,55 sys
244,88 real 1041,61 user 331,53 sys
238,77 real 1028,97 user 324,27 sys

With -XX:+UseSerialGC
242,03 real 1008,41 user 328,66 sys
240,41 real 1013,91 user 322,72 sys
241,01 real 1032,61 user 334,18 sys
240,78 real 1018,91 user 326,91 sysa
246,80 real 1019,30 user 329,62 sys

Aarch64/linux 8 cores/threads

With -XX:+UseG1GC
3609.77 user 397.28 system 10:50.72 elapsed 615%CPU
3609.06 user 399.17 system 10:50.69 elapsed 615%CPU
3603.77 user 398.48 system 10:47.87 elapsed 617%CPU
3607.01 user 397.20 system 10:48.46 elapsed 617%CPU
3610.96 user 397.54 system 10:50.47 elapsed 616%CPU

With -XX:+UseSerialGC
3594.05 user 390.28 system 10:47.74 elapsed 615%CPU
3598.96 user 393.94 system 10:48.69 elapsed 615%CPU
3603.72 user 400.47 system 10:52.30 elapsed 613%CPU
3598.58 user 395.28 system 10:50.41 elapsed 614%CPU
3597.56 user 396.53 system 10:46.82 elapsed 617%CPU

x86/linux 18cores/36 threads

With -XX:+UseG1GC

7832.05 user 312.06 system 5:14.24 elapsed 2591% CPU
7857.10 user 311.21 system 5:13.48 elapsed 2605%CPU
7863.41 user 311.84 system 5:14.73 elapsed 2597%CPU
7861.16 user 310.59 system 5:13.34 elapsed 2607%CPU
7859.08 user 312.54 system 5:14.76 elapsed 2596%CPU

With -XX:+UseSerialGC

7947.52 user 411.59 system 5:20.41 elapsed 2608% CPU (not sure, seems outlier)
7949.13 user 404.06 system 5:19.74 elapsed 2612% CPU (not sure, seems outlier)
7856.50 user 317.78 system 5:13.77 elapsed 2605% CPU
7853.48 user 312.27 system 5:15.62 elapsed 2587% CPU
7853.75 user 311.70 system 5:14.65 elapsed 2595% CPU

To me this is significantly enough to be the same (comparing e.g. user times differences are very small), so I will go ahead removing the flags.

[shipilev]

To me this is significantly enough to be the same (comparing e.g. user times differences are very small), so I will go ahead removing the flags.

Agreed, these look similar enough not to specialize with Serial. Also serves as an evidence that doing JEP 523 is the right thing. I think it still makes sense to keep heap size limits, though.

[shipilev]

Not sure what test/hotspot/gtest/gc/serial/test_collectorPolicy.cpp move is about in this changeset.

[xmas92]

👍 On this change. Very nice that we can do this without degradation to the build times.

Should the issue title reflect that this is now just "use the default GC when building"?

[tschatzl]

👍 On this change. Very nice that we can do this without degradation to the build times.

Should the issue title reflect that this is now just "use the default GC when building"?

No. There is still the issue with the serial-gc specific test being in the wrong directory. It will fail building if serial gc is not built in.

I will separate these issues, this one for the serial gc gtest move, and another for the default gc.