RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v21]
Mandy Chung
mchung at openjdk.org
Mon Mar 18 20:20:32 UTC 2024
On Fri, 15 Mar 2024 15:19:17 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 two additional commits since the last revision:
>
> - Fix comment.
> - Review feedback and Windows build fix (FixPath)
This is what I understand from your implementation:
1. create a regular JDK image under `support/images/runtime-link-initial-jdk` using jlink from the exploded JDK build
2. create a linkable JDK image under `images/jdk` using jlink from the exploded JDK build with jlink command-line options used in step 1 plus
-create-linkable-runtime jimage=support/images/runtime-link-initial-jdk/lib/modules:module-path=support/images/jmods
jlink in step 2 has to run through the plugin pipeline as in step 1 and also the `create-linkable-runtime` plugin to generate the diffs and record the metadata for reconstituting the modules from the images (without the packaged modules).
Step 2 re-creates a new jimage file from the input packaged modules while the diffs are generated from `runtime-link-initial-jdk/lib/modules`. In this approach, step 1 and step 2 assume that the same set of modules are linked and set set of plugin transformation is applied except `--create-linkable-runtime` as in step 1, i.e. it relies on the makefile to pass proper commands to step 1 and step 2 to result in the same `lib/modules` minus the new metadata and diffs added by `--create-linkable-runtime`.
The original idea we discussed is that step 1 creates a normal JDK image (as step 1 above) and then step 2 solely creates a new JDK linkable image without involving plugin pipeline that would be a simpler model. The idea was something like this:
$ runtime-link-initial-jdk/bin/jlink -create-linkable-runtime support/images/jmods --output images/jdk
jlink `--create-linkable-runtime` will copy everything under `runtime-link-initial-jdk` (the runtime executing jlink) except `lib/modules` to `images/jdk` and create a new jimage `lib/modules` from `runtime-link-initial-jdk/lib/modules` (include diffs and metadata files).
Have you seen any issues with this approach over your current approach which involves the plugin transformation in both step 1 and 2?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2004888430
More information about the core-libs-dev
mailing list