On Tue, 5 Dec 2023 19:15:53 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >> install might not come with the packaged modules (directory `jmods`). This >> is particularly useful to further reduce the size of a jlinked runtime. >> After the removal of the concept of a JRE, a common distribution mechanism >> is still the full JDK with all modules and packaged modules. However, >> packaged modules can incur an additional size tax. For example in a >> container scenario it could be useful to have a base JDK container including >> all modules, but without also delivering the packaged modules. This comes at >> a size advantage of `~25%`. Such a base JDK container could then be used to >> `jlink` application specific runtimes, further reducing the size of the >> application runtime image (App + JDK runtime; as a single image *or* >> separate bundles, depending on the app being modularized). >> >> The basic design of this approach is to add a jlink plugin for tracking >> non-class and non-resource files of a JDK install. I.e. files which aren't >> present in the jimage (`lib/modules`). This enables producing a `JRTArchive` >> class which has all the info of what constitutes the final jlinked runtime. >> >> Basic usage example: >> >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules java.se) >> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules jdk.jlink) >> $ ls ../linux-x86_64-server-release/images/jdk/jmods >> java.base.jmod java.net.http.jmod java.sql.rowset.jmod >> jdk.crypto.ec.jmod jdk.internal.opt.jmod >> jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod >> java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod >> jdk.dynalink.jmod jdk.internal.vm.ci.jmod >> jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod >> java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod >> jdk.editpad.jmod jdk.internal.vm.compiler.jmod >> jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod >> java.desktop.jmod java.scripting.jmod java.xml.jmod >> jdk.hotspot.agent.jmod jdk.i... > > Severin Gehwolf has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 46 commits: > > - Add @enablePreview for JImageValidator that uses classfile API > - Fix SystemModulesPlugin after merge > - Merge branch 'master' into jdk-8311302-jmodless-link > - Don't show the verbose hint when already verbose > - Use '_files' over '_resources' as the suffix for listing resources > - Remove the hidden option hint. > > Also adjust the messages being printed when performing > a run-time image link. > - Localize messages, switch expression > - Rename RunImageArchive => JRTArchive and RunImageLinkException => > RuntimeImageLinkException > > Also moved the stamp file to jdk.jlink module. The resources files per > module now get unconditionally created (empty if no resources not in the > jimage). > - First round of addressing review feedback. > > - Share resource names (JlinkTask and JlinkResourcesListPlugin) > - Exclude resources in JlinkResourcesListPlugin the same way > as done for other plugins. > - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin > - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69 > I tried out the latest commit > ([a797ea6](https://github.com/openjdk/jdk/commit/a797ea69bc2852a843f2c8cc4d4fcd18f1468682)). Thanks for trying. > The output "The default module path, '$java.home/jmods' not present. Use > --verbose to show the full list of plugin options applied" is bit confusing > as it looks like jlink failed but it actually succeeded. I've changed the message printed for run-time image based links based on [review feedback](https://github.com/openjdk/jdk/pull/14787#issuecomment-1830528390). Happy to change that to whatever seems most amenable. > Blowing away the generated image and retrying with --verbose tripped this > assert > > ``` > java.lang.AssertionError: handling of scratch options failed > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675) > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581) > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302) > at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56) > at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34) > Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: > (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already > exists > at > jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730) > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183) > at > jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177) > at > jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600) > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672) > ... 5 more > ``` Could you please provide steps to reproduce this? > I haven't dug into this yet but I'm puzzled that the file path to where the > original build was created is in the exception messages, is that recorded? Yes, in order to determine the plugin options that are being applied that is needed. I.e. a link using packaged modules - step 1 - will create a `jdk/tools/jlink/internal/cli_cmd.txt` file in the jimage, with the cli options that were used. Those options are then merged with a potential run-time image link - step 2 - after (if `jdk.jlink` was part of the original link) in order to figure out the plug-in options which were used in the packaged modules link step. The goal was to show the equivalent `jlink` command to use when only using packaged modules. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1849709413
