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

[Severin Gehwolf]

On Mon, 18 Mar 2024 20:18:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This is what I understand from your implementation:
> 
>     1. create a regular JDK image under `support/images/runtime-link-initial-jdk` using jlink from the exploded JDK build
> 
>     2. create a linkable JDK image under `images/jdk` using jlink from the exploded JDK build with jlink command-line options used in step 1 plus
> 
> 
> ```
> -create-linkable-runtime jimage=support/images/runtime-link-initial-jdk/lib/modules:module-path=support/images/jmods
> ```
> 
> jlink in step 2 has to run through the plugin pipeline as in step 1 and also the `create-linkable-runtime` plugin to generate the diffs and record the metadata for reconstituting the modules from the images (without the packaged modules).
> 
> Step 2 re-creates a new jimage file from the input packaged modules while the diffs are generated from `runtime-link-initial-jdk/lib/modules`. In this approach, step 1 and step 2 assume that the same set of modules are linked and set set of plugin transformation is applied except `--create-linkable-runtime` as in step 1, i.e. it relies on the makefile to pass proper commands to step 1 and step 2 to result in the same `lib/modules` minus the new metadata and diffs added by `--create-linkable-runtime`.

That's correct.

> The original idea we discussed is that step 1 creates a normal JDK image (as step 1 above) and then step 2 solely creates a new JDK linkable image without involving plugin pipeline that would be a simpler model. The idea was something like this:
> 
> ```
> $ runtime-link-initial-jdk/bin/jlink -create-linkable-runtime support/images/jmods --output images/jdk
> ```
> 
> jlink `--create-linkable-runtime` will copy everything under `runtime-link-initial-jdk` (the runtime executing jlink) except `lib/modules` to `images/jdk` and create a new jimage `lib/modules` from `runtime-link-initial-jdk/lib/modules` (include diffs and metadata files).
> 
> Have you seen any issues with this approach over your current approach which involves the plugin transformation in both step 1 and 2?

Yes, a couple of issues. In no particular order:

- `jlink` is the only tool capable of generating the `jimage` file (`lib/modules`) as of yet. See class `ImageFileCreator`.
- `jlink` is currently designed in a way to work on a) some form of an `Archive` (packaged modules, really) and b) a plugin pipeline. a) changes with this patch due to introduction of `JRTArchive`, but this archive relies on the "diff parts" as well as the "non-class-resource" parts. So in order to "use" `lib/modules` from `runtime-link-initial-jdk` we have a chicken and egg problem: Use `JRTArchive` before it's ready to be used. Or we'd have to distinguish between `JRTArchive` usage at JDK build time and `JRTArchive` usage at jlink runtime (after the JDK build has completed).
- Let's assume the `JRTArchive` issue as described above is solved then we wouldn't have a way to **not** run any plugins at jlink time, unless we specify `--disable-plugin <name>` for each. Even if we had, then there is no guarantee to present the resources in the `jimage` file in the desired order.
- Let's assume we don't use `JRTArchive` and use an `Archive` implementation from packaged modules instead. We cannot use that approach either, since we'd miss generated resources from plugins (like `--system-modules`, `--release-info` and `--generate-jli-classes`) or change the order of the resources in the `jimage` (plugin `--order-resources`) or have a different compression level (plugin `--compress`). There is more, which affects generation of the actual `jimage` file.
- The way I understand the `jimage` [format](https://cr.openjdk.org/~sgehwolf/leyden/jimage_visualization_1.png) and how it's generated, it doesn't allow for post-factum addition of resources for a module. Those need to be known at jlink pipeline run time so that this information is available when the actual image format is being serialized.

So unless, I'm missing something, the approach that I've taken would be the one with less compatibility impact. Thoughts?

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

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