RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v7]

[Mandy Chung]

On Mon, 13 Nov 2023 17:00:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a "jmodless" jlink mode to the JDK. 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 `JmodLessArchive` 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 java.se) <(../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.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.j...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Add a message when a run-image based link is being performed
>  - Add hint to the modified file case
>  - AddJmodResourcesPlugin => AddRunImageResourcesPlugin rename
>  - --add-jmod-resources => --add-run-image-resources rename
>    
>    Also rename jmod_resources to runimage_resources
>  - Improve error message of run-image recursive link
>  - Use a single option --unlock-run-image for single hop and warnings
>  - JmodLessArchive => RunImageArchive rename
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Work-around JDK-8317609 (jdk.jcmd module doesn't verify)
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/73e75197...fea34e3a

I did one pass through the changes.   Looks like the plugin author has to consider how it should work to support linking without packaged modules.

The current implementation `--system-modules` re-applies for every jlink invocation since the transformation depends on the set of modules to be linked in the resulting image.

OTOH `--vendor-bug-url`, `--vendor-version` and `--vendor-vm-bug-url` plugins are auto-applied
to the new image created via this run-time image based linking when these options  are not specified.

I was wondering what plugins that were applied in the first image are carried automatically during the run-time image based linking?  I would assume this will generate an image equivalent to running jlink with the packaged modules present.  Therefore nothing should be carried automatically from the current run-time image, shouldn't it?

I agree that `--add-run-image-resources` should be hidden and it's not target for developers to use.  I consider it's jlink internal implementation.    It's auto-enabled  and always generates the per-module `runimage_resources`.   I think we might need to add `Plugin::showPlugin` or `hidePlugin` to specify if this plugin should be hidden from `--list-plugins`.

It's good to move `runimage_resources` to some package under `jdk/internal` but each module will need to be a different package name.    BTW I found `runimage` a confusing term. 

I am also not certain if we should support `--unlock-run-time` option.   Are you trying to make the users do less work to configure some properties files once in the first image and all the custom runtime images created from that will not need to do the configuration?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1809458530