On Tue, 27 Feb 2024 15:23:09 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 incrementally with one > additional commit since the last revision: > > Only show runtime image suffix for JDK modules > > What is the rationale for introducing a special configure flag for this > > functionality? I've tried to look though all comments in this PR, and read > > the JBS issue and CSR, but I have not found any motivation for this. I'm > > sorry if it's there and I missed it, but this is a huge PR with a lot of > > discussion. > > In general, it is better not to introduce variants of the build like this. > > The testing matrix just explodes a bit more. And my understanding from the > > discussion is that this functionality is likely to be turned on anyway, > > otherwise you'll build a crippled jlink without full functionality. > > I have no opinion on whether the opt-in is at configure time or its just make > target (like "make legacy-jre-image"). In the discussions it wasn't meant to > be built by default. If distributions choose to distribute this image then > this will likely influence what they test. Once experience builds up with > using these run-time images then it may be that there is a proposal (and JEP) > to make it the default, meaning images/jdk would not include .jmod files and > multi-hop restriction is removed from jlink. That may be something for much > further down the road. The choice between a configure option to modify the meaning of the `jdk-image` target (and subsequently the `product-bundles` target), and adding an additional `foo-image` target (and bundle definition) mainly comes down to if there is ever a usecase for producing both the current/default jdk image and this new image side by side. Back when we still had a JRE, producing both the JDK and JRE from the same build was required as they were two different supported distributions that users were expected to pick between depending on usecase. This option however sounds much more like an either or choice for the OpenJDK distributor. Unless RedHat is planning on distributing both variants side by side, the configure option makes the most sense. It minimizes the need for further modifications of the makefiles (for defining a new bundle for this new image), the test makefiles (for defining a way to run tests on this new image), and other parts of the build pipeline for anyone who wants to build and distribute this new image. Based on that I agree with the choice of using a configure argument. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1988436548
