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

2024-08-12 Thread Severin Gehwolf
On Mon, 24 Jun 2024 14:33:51 GMT, Severin Gehwolf  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.jmodjava.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.jmodjava.prefs.jmod  java.transaction.xa.jmod  
>> jdk.dynalink.jmod  jdk.internal.vm.ci.jmod   
>> jdk.jdwp.agent.jmod  jdk.management.jfr.jmodjdk.security.jgss.jmod
>> java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod  
>> jdk.editpad.jmod   jdk.internal.vm.compiler.jmod 
>> jdk.jfr.jmod jdk.management.jmodjdk.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 137 commits:
> 
>  - JLinkDedupTestBatchSizeOne.java test fix
>
>Run only the packaged modules version if we have a linkable JDK runtime
>with packaged modules available as well in the JDK install.
>  - Enable IncludeLocalesPluginTest
>  - Enable GenerateJLIClassesPluginTest.java test
>  - Enable JLinkReproducibleTest.java for linkable JDK images
>  - Remove restriction on directory based modules
>
>Enable the following tests:
>- JLink100Modules.java
>- JLinkDedupTestBatchSizeOne.java
>  - Comment fix in JRTArchive. Long line in JlinkTask
>  - Comment fixes in ImageFileCreator
>  - Comments and clean-up in JlinkTask
>  - Helper support for linkable JDK runtimes
>  - Test clean-up. class-file API module.
>  - ... and 127 more: https://git.openjdk.org/jdk/compare/5cad0b4d...04cd98f8

Please keep it open bot.

-

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


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

2024-06-25 Thread Severin Gehwolf
On Mon, 24 Jun 2024 14:33:51 GMT, Severin Gehwolf  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.jmodjava.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.jmodjava.prefs.jmod  java.transaction.xa.jmod  
>> jdk.dynalink.jmod  jdk.internal.vm.ci.jmod   
>> jdk.jdwp.agent.jmod  jdk.management.jfr.jmodjdk.security.jgss.jmod
>> java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod  
>> jdk.editpad.jmod   jdk.internal.vm.compiler.jmod 
>> jdk.jfr.jmod jdk.management.jmodjdk.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 137 commits:
> 
>  - JLinkDedupTestBatchSizeOne.java test fix
>
>Run only the packaged modules version if we have a linkable JDK runtime
>with packaged modules available as well in the JDK install.
>  - Enable IncludeLocalesPluginTest
>  - Enable GenerateJLIClassesPluginTest.java test
>  - Enable JLinkReproducibleTest.java for linkable JDK images
>  - Remove restriction on directory based modules
>
>Enable the following tests:
>- JLink100Modules.java
>- JLinkDedupTestBatchSizeOne.java
>  - Comment fix in JRTArchive. Long line in JlinkTask
>  - Comment fixes in ImageFileCreator
>  - Comments and clean-up in JlinkTask
>  - Helper support for linkable JDK runtimes
>  - Test clean-up. class-file API module.
>  - ... and 127 more: https://git.openjdk.org/jdk/compare/5cad0b4d...04cd98f8

I've pushed some clean-up fixes to this PR so as to fix the overly long lines 
and added comments to relevant methods. The latest GHA failure on MacOSX x86_64 
is infra related.

-

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


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

2024-06-24 Thread Severin Gehwolf
> 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 b
 eing 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.jmodjava.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.jmodjava.prefs.jmod  java.transaction.xa.jmod  
> jdk.dynalink.jmod  jdk.internal.vm.ci.jmod   
> jdk.jdwp.agent.jmod  jdk.management.jfr.jmodjdk.security.jgss.jmod
> java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod  
> jdk.editpad.jmod   jdk.internal.vm.compiler.jmod 
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod  java.xml.jmod 
> jdk.hotspot.agent.jmod jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 137 commits:

 - JLinkDedupTestBatchSizeOne.java test fix
   
   Run only the packaged modules version if we have a linkable JDK runtime
   with packaged modules available as well in the JDK install.
 - Enable IncludeLocalesPluginTest
 - Enable GenerateJLIClassesPluginTest.java test
 - Enable JLinkReproducibleTest.java for linkable JDK images
 - Remove restriction on directory based modules
   
   Enable the following tests:
   - JLink100Modules.java
   - JLinkDedupTestBatchSizeOne.java
 - Comment fix in JRTArchive. Long line in JlinkTask
 - Comment fixes in ImageFileCreator
 - Comments and clean-up in JlinkTask
 - Helper support for linkable JDK runtimes
 - Test clean-up. class-file API module.
 - ... and 127 more: https://git.openjdk.org/jdk/compare/5cad0b4d...04cd98f8

-

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=32
  Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787