On Mon, 11 Dec 2023 16:37:38 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 two > additional commits since the last revision: > > - Disallow packaged modules and run-time image link > - Only check for existing path when not a scratch task > > When using a run-time image link and the initial build was produced with > the --keep-packaged-modules option, we don't need to check existing > paths to the location where packaged modules need to be copied. This > breaks the --verbose output validation. FWIW. [f623930](https://github.com/mlchung/jdk/commit/f623930cd529085ddb730a60b7facf106ea01955) for your reference. I pulled your branch and refactored and made suggestions to the code while I was walking through the code. Some observations: The constants such as the pathname of the timestamp file and the internal file listing per-module non-class non-resource files are part of jlink. I move the constants to `JlinkTask`to follow where `OPTIONS_RESOURCE` is defined. `JRTArchive` scans the class and resource files of a given module from the runtime image. It should also read `fs_$MODULE_files` to find the list of non-class and non-resource files. The current implementation checks if a file is modified lazily when `Entry::stream` is called and so it has to remember if file modification has been checked and warning has been emitted. I think doing the file modification check eagerly when `collectFiles` is called would simplify the code. For maintainability, better to move the reading of and writing to `fs_$MODULE_files` together in a single class rather than separated in `JRTArchive` and `JlinkResourcesListPlugin`. I move them to `JRTArchive.ResourceFileEntry` for now. There may be a better place. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1863338821
