Repository navigation
Conversation
…DS archive The heap of the compiler and the language server is millions of small objects, and compact object headers took 6% off the heap of the language server on castle fight (488 to 457 MB after a collection) at the same start time. A JVM uses a base CDS archive only for the object header mode it was started with, so the runtime ships the archive for that mode and every launcher passes the option. - jlink no longer makes the archive: it writes it for the options of the JVM it starts, which the JAVA_TOOL_OPTIONS of the build machine change (CI exports -XX:+UseCompactObjectHeaders, which left only classes_coh.jsa). The build runs java -XX:+UseCompactObjectHeaders -Xshare:dump on the image instead, with the option variables removed, and ships only that archive. - assembleSlimCompilerDist starts the runtime with -Xshare:on, which fails without a usable archive, instead of looking for a file name. - The launchers (wurstscript, grill, and their .cmd files) pass -XX:+UseCompactObjectHeaders.
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4b4f61a2e1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
… stays in it The folder is zipped as it is. A Copy only adds to it, so a checkout whose dist folder came from an earlier build (with classes.jsa, the archive of the other header mode) shipped both archives.
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
Closing: the shipped JRE is being upgraded to 27 by another change, which makes this rework unnecessary. |
What
The compiler and the language server hold millions of small objects, so they should run with compact object headers (
-XX:+UseCompactObjectHeaders, a product flag since JDK 25). Users could already ask for it inwurst.javaOpts, and CI exports it for the tests; nothing in the distribution made it the default. Giving the option twice (launcher plusjavaOptsorJAVA_TOOL_OPTIONS) is harmless: the JVM takes the last one, and the checks below cover it.A JVM uses a base CDS archive only for the object header mode it was started with. #1386 made the base archive with
jlink --generate-cds-archive, which writes it for the options of the JVM jlink starts, so it came out asclasses.jsaon a developer machine and asclasses_coh.jsaon CI (which exportsJAVA_TOOL_OPTIONS=-XX:+UseCompactObjectHeaders). Making compact headers the default needs the archive to be the one for that mode, whatever the build machine exports.deploy.gradleno longer asks jlink for the archive. After jlink it runsjava -XX:+UseCompactObjectHeaders -Xshare:dumpon the image, withJAVA_TOOL_OPTIONS,_JAVA_OPTIONSandJDK_JAVA_OPTIONSremoved, and ships only that archive (classes_coh.jsa, 14.6 MB). macOS copies a full JDK, which has it.assembleSlimCompilerDiststarts the runtime with-XX:+UseCompactObjectHeaders -Xshare:on, which fails when there is no usable archive. That replaces looking for a file name.launchers/wurstscript,wurstscript.cmd,grill,grill.cmdpass-XX:+UseCompactObjectHeaders.AGENTS.md("Language server startup archive") andCHANGELOG.mdstate the contract.Companion changes: wurst4vscode (the language server's own launch) and grill (WurstSetup) pass the same flag.
Measured
Language server on castle fight, start to the initial build being ready, three interleaved starts each (full Temurin 25 JDK):
-XX:+UseCompactObjectHeadersThe built distribution from this branch (runtime with
classes_coh.jsa, extension flags-XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=… -Xlog:disable): 19.0 s for the first start (which writes the 30.6 MB application archive), then 18.0 s and 18.0 s.Checks
./gradlew assembleSlimCompilerDiston Windows:bin/serverholdsclasses_coh.jsaonly;java -XX:+UseCompactObjectHeaders -Xshare:on -versionexits 0, and without the option it exits 1 (no archive for that header mode), so the guard is meaningful.JAVA_TOOL_OPTIONS="-XX:+UseCompactObjectHeaders -XX:+UseStringDeduplication --enable-native-access=ALL-UNNAMED"set (the CI case): the same single archive.-XX:+UseCompactObjectHeadersin the launcher and again inwurst.javaOpts, or inJAVA_TOOL_OPTIONSas well) starts with-Xshare:on, exit 0; so does on, off, on.assembleSlimCompilerDistis aSyncnow: a staleclasses.jsaand a stray file left inbuild/dist/slim-win-x64by an earlier build are removed by the next run.-Xshare:onstart fails the build if a runtime has no usable archive).