On Fri, 8 Mar 2024 19:49:19 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>>> > @AlanBateman @mlchung I've now pushed an update of this patch which now >>> > uses a build-time approach as discussed elsewhere. In order to produce a >>> > linkable runtime JDK image, one needs to set --enable-runtime-link-image >>> > at configure time. >>> >>> What is the rationale for introducing a special configure flag for this >>> functionality? I've tried to look though all comments in this PR, and read >>> the JBS issue and CSR, but I have not found any motivation for this. I'm >>> sorry if it's there and I missed it, but this is a huge PR with a lot of >>> discussion. >> >> Sorry, yes this was part of a meeting discussion we had outside this PR. My >> understanding is that by default the produced jimage isn't runtime-link >> enabled. We (Red Hat) would turn it on in our builds, though. @AlanBateman >> or @mlchung might have more details. I think it was a requirement to get >> this patch in. At least for the initial contribution. >> >>> In general, it is better not to introduce variants of the build like this. >>> The testing matrix just explodes a bit more. And my understanding from the >>> discussion is that this functionality is likely to be turned on anyway, >>> otherwise you'll build a crippled jlink without full functionality. >> >> I would be happy if this could be on by default. For now, I think though we >> need to work on the premise that whether or not the resulting JDK image is >> suitable for runtime linking (without jmods) is a build-time config >> decision. Therefore we need the configure option. > > @jerboaa thanks for the update. First to recap the revised proposal (based > on Alan's notes shared with me earlier): > > The JDK build is capable of producing a JDK run-time image that does not > include packaged modules and the new JDK image is capable to create custom > run-time images (call it "linkable" JDK image for now). To reconstitute to > the original module content, the new JDK image conceptually needs to contain > the "diffs" from the original packaged packaged. This makes it possible for > the jlink plugins to run "as if" the resources for each module were coming > from the original packaged module. The new image also has the checksums of > at least the user-editable configuration files so that edits can be detected. > > The revised proposal has a few limitations: > > 1. The "linkable" JDK image can only be created by the JDK build. > 2. The "linkable" JDK image is created from the JDK image produced by the JDK > build today. It contains the same set of modules, there is no possibility to > combine its generation with other jlink options or code transformations. > 3. The "linkable" JDK image cannot create a run-time image that contains the > "jdk.jlink" module. > 4. The "linkable" JDK image only reconstitutes classes/resources to the > original module bits. Other plugins such as man pages and dedup legal files > are not reconstituted. > > These limitations are trade-off to make for a much simpler approach. It > removes the issues of creating a linkable JDK, or creating another image > using a linkable JDK, while at the same time executing a pipeline of plugins > that do other transformations. > > Here is my feedback to the prototype: > > - I think the reader and writer code for generating the diffs should be in > `jdk.jlink` so that they are always kept in sync. > - The diffs generation can be done as a tool or `jlink` option. If it's a > tool, it should be run on the interim image (like the tool generating > classlist - see `GenerateLinkOptData.gmk`). > > I have no strong opinion in which approach. It seems worth exploring the > tool approach residing in `jdk.jlink` to generate the diffs as well as create > the linkable image could remove the need of a jlink internal > `--create-linkable-runtime` option. Hi @mlchung! > Here is my feedback to the prototype: > > * I think the reader and writer code for generating the diffs should be > in `jdk.jlink` so that they are always kept in sync. Done in the update. The duplication of `ResourceDiff` is now gone. > * The diffs generation can be done as a tool or `jlink` option. If it's > a tool, it should be run on the interim image (like the tool generating > classlist - see `GenerateLinkOptData.gmk`). > > I have no strong opinion in which approach. It seems worth exploring the tool > approach residing in `jdk.jlink` to generate the diffs as well as create the > linkable image could remove the need of a jlink internal > `--create-linkable-runtime` option. The updated patch uses a **build-only** `jlink` plugin, still called `--create-linkable-runtime` which is *a)* added only at build time with `--add-modules` and *b)* now generates the diff and prepares the image for runtime linking as before in one step. The code for this now lives in `src/jdk.jlink/build/classes`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1997560773
