RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]
Mandy Chung
mchung at openjdk.org
Thu Mar 14 20:57:45 UTC 2024
On Thu, 14 Mar 2024 14:24:57 GMT, Severin Gehwolf <sgehwolf at 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 incrementally with one additional commit since the last revision:
>
> Fix comment in autoconf file
> The updated patch uses a **build-only** `jlink` plugin, still called `--create-linkable-runtime` which is _a)_ added only at build time with `--add-modules` and _b)_ now generates the diff and prepares the image for runtime linking as before in one step. The code for this now lives in `src/jdk.jlink/build/classes`.
This patch introduces a new module `jdk.unsupported_jlink_runtime` . `src/jdk.jlink` should only contain one module (see JEP 201). If it ought to have another module, its source files should be placed under `src/$MODULE`.
I would suggest to simplify it - drop the new module `jdk.unsupported_jlink_runtime` and simply include all its classes in `jdk.jlink` module; for example in `jdk.tools.jlink.internal.runtimelink` package to follow the existing jlink package name hierarchy. This package can only be compiled when JDK is configured to build linkable images. The build can simply invoke `jlink --create-linkable-runtime` and avoids all the setup to add exports to this build tool. If jlink is running from a linkable image, --create-linkable-runtime` plugin should be disabled and hidden. What do you think?
About the configure options,
--enable-keep-packaged-modules
enable keeping of packaged modules in jdk image [enabled]
--enable-runtime-link-image
enable producing an image suitable for runtime linking [disabled]
If `--enable-runtime-link-image` is enabled, the JDK image does not include the packaged modules. If `--enable-runtime-link-image --enable-keep-packaged-modules` are both enabled, it should probably fail? @erikj79 should it?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1998467918
More information about the build-dev
mailing list