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

[Mandy Chung]

On Wed, 6 Nov 2024 11:24:23 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 with a new target base due to a merge or a rebase. The pull request now contains 180 commits:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Make capability in --help human readable
>  - Fix comment
>  - Fix SystemModulesTest2 when linkable runtime but no packaged modules
>  - Rename PackagedModulesVsJmodLessTest => PackagedModulesVsRuntimeImageLinkTest
>  - Rename JmodLess => runtimeImage
>  - Refactor tests so that they run for default build
>    
>    When a default JDK build is being produced, the tests create a run-time
>    image capable JDK as an interim step before everything else is being
>    verified.
>    
>    For a build that has the run-time image link capability already turned
>    on, this extra step is being omitted.
>  - Mandy's feedback
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Some test fixes
>  - ... and 170 more: https://git.openjdk.org/jdk/compare/83f3d42d...e83b9584

Another question about the tests.  Most of the tests have 2 `@test id=XXX` for example `@test id=packaged_modules` requires `jlink.packagedModules` `@test id=linkable_jdk_runtimes` requires `jlink.runtime.linkable & !jlink.packagedModules`.   Similarly, the new `runtimeImage` tests have `@test id=default_build` and `@test id=linkable_runtime`.  `@run` is passed with an additional argument (true or false) to the main program to indicate the JDK configuration.

For each test execution with one test JDK which is built with one configuration, it can only have at most one test run and the other `@test` will be skipped. It seems to me that it's much simpler to keep it a single `@test` instead of 2 different `@test` (avoid duplicating with all test tags) and have the main method to determine if the JDK is linkable run-time image and it has packaged modules via test library.  Or am I missing something of testing story?

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

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