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

[Mandy Chung]

On Mon, 11 Dec 2023 16:37:38 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:
> 
>  - 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.

> Which filtering plugins do you see with category TRANSFORMER? perhaps? Happy to move them to the FILTER category.

Yes `strip-java-debug-attributes` and `strip-native-debug-symbols`  are the ones.  `dedup-legal-notices` is another one.

> > The use of `--exclude-resources` plugin to exclude transformed data to restore the data back to original form is clever and works for plugins that add new resources. But it does not work for plugins that modifying existing data (`--vendor-bug-url` etc plugins). The change in `TaskHelper::getPluginsConfig` raises the question that it isn't the right way to support this feature. I think we need to explore a better way to add this support. One possibility I consider is to run non-filtering plugins of ADDER and TRANSFORMER categories always (similar to auto-enabled). It has to determine if it's requested by the user or to restore the data to original form via `Plugin::configure` time. `Plugin::transform` will handle if the data is from packaged-modules and from runtime image which may contain the data transformed by this plugin. I haven't explored this fully yet. More discussion is needed and Alan may have opinions.
> 
> So would it be acceptable if I changed those plugins to restore the old behaviour if they were not requested by the user with the respective cli option? Basically, my thinking would be that `Plugin::configure` would gain extra argument so as to determined whether this is a runtime-image based link and triggered by the current jlink run with its CLI option. This should be sufficient to configure for `transform` appropriately.

My intent is to bring up my observation for discussion.   The plugin authors are the ones who should decide if the plugin should restore the data from the runtime image to original form.    It needs a way to indicate that the transformed data won't persist for this plugin.  So far I think `FILTER` category may be adequate but it may be better to define a new type.   This requires some prototype to determine what is the right way.

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

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