RFR: 8311302: Implement JEP 493: Linking Run-Time Images without JMODs [v40]

[Mark Reinhold]

On Fri, 25 Oct 2024 16:29:52 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 five additional commits since the last revision:
> 
>  - Better handle patched modules
>    
>    Also add a test which ensures that module patching (if present), will
>    get an appropriate error message.
>  - Add /othervm to some langtools tier1 tests
>    
>    Those tests are using module patches from JTREG. Since the run-time
>    image based link uses ModuleFinder.ofSystem(), which will see the extra
>    classes comming from the module patch. Then the size look-up using the
>    JRT FS provider fails, since that only looks in the module image
>    (lib/modules) and NOT also in the patch. Thus, we get a
>    NoSuchFileException and the link fails.
>    
>    Run the tests with othervm so that the JTREG patch'ed module isn't
>    visible to the test.
>  - Fix tests for builds with --enable-linable-runtime
>    
>    Those builds don't include the packaged modules, `jmods` directory.
>    However, some tests assume that they're there. Add appropriate requires
>    tag.
>  - Fix provider verification when some JMODs are present
>    
>    In some configurations, e.g. when java.base is missing from the packaged
>    modules, but another JDK module is present as JMOD that is linked into
>    an image, then provider verification can fail. Thus, the run-time image
>    link fails. Verify that this doesn't happen.
>    
>    The fix is to return Platform.runtime() for run-time image based links
>    as well. Otherwise this code would return the wrong result.
>  - Show run-time image based capability in help
>    
>    Also add a test for it when it's turned on and off.

Changes requested by mr (Lead).

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 119:

> 117: warn.prefix=Warning:
> 118: 
> 119: err.runtime.link.not.linkable.runtime=The current run-time image does not support run-time linking.

Please remove the trailing periods from the new messages. The existing messages don’t use them, and JDK command-line tools in general don’t use them.

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

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2399260041
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1819168717