jmods-less jlinking prototype

[Dan Heidinga]

On Fri, Mar 17, 2023 at 5:35 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 15/03/2023 16:57, Severin Gehwolf wrote:
> > :
> > I'd argue that the case where users actually want things back (add
> > back, rather than remove) from any base JDK image is rather small.
> > Though, I have no numbers about this so this is only anecdotal. Have
> > you seen use-cases doing that (add-back, taking from jmods)?
>
> Almost every usage that I've observed has been reduction and one jlink
> step to create a small run-time image. It's always start with a JDK
> build with packaged modules and then jlink to generate a run-time image
> with the subset of the standard and JDK modules that the application
> needs. Some sightings have included jlink options to compress or strip
> debug attributes, just to get the size down. I haven't seen any usages
> of --keep-packaged-modules so the resulting run-time couldn't be used to
> stamp out another run-time image, at least not without specifying
> -module-path and of course including the jdk.jlink module.
>

Severin and I talked about whether to always include jdk.jlink as part of
his prototype but finally opted not to as some users may not want it.

We also talked about some of the ways jlink (condensers) can be set up.
The obvious first case is as it is today: generating an image starting from
the JDK & jmod files.
JDK+jmods --- jlink ---> runtime image + modules file

Severin's prototype is another point on the spectrum where some condensers
(jlink plugins) have been run and modified the image in various ways (ie:
making it platform-specific, pre-gening the jli classes, etc) making it
more ready for deployment.  Many of the customizations have been captured
in the modules file - new classes, modified classes, etc - so using the
modules file as input to the next jlink is important to not lose those
customizations.  As Severin's prototype shows, the modules file is not
sufficient on its own - we still need the rest of the JDK and the various
config files, etc that go along with each module.  Today, we don't have
users doing this as this kind of re-jlink as they don't have the jmods in
their image anymore.

JDK+jmods --- jlink ---> runtime image + modules file  --- jlink ---> new
runtime image + new modules file

There's another option though which avoids needing jdk.jlink to be included
in the intermediate images.  We could use a separate JDK to do the jlink
process and allow it to use the runtime image+modules file as the input to
the process.  This has jlink act as a tool on the side, operating on either
the JDK+jmods or the runtime image+modules file.  We don't need jlink to be
in the image, just available in some JDK that can operate on the image.

JDK+jmods --- jlink ---> runtime image + modules file
runtime image + modules --- JDK's jlink ---> new runtime image + new
modules file

We can grow Severin's prototype to eventually allow this later form as well
once we've nailed down the current behaviour.


> The only of additive case that I've come across is with the GraalVM
> build where they use the jlink --add-option to add VM options to select
> the Graal JIT. This works by adding a resource to the java.base module.
> More recently,  --save-jlink-argfiles has been added so the options are
> preserved for future stamping of out of images. I haven't seen any
> usages of this yet but it would need to be paired with
> --keep-packaged-modules to be useful. Your prototype avoid needing that
> of course.
>

Thanks for mentioning the  --save-jlink-argfiles option.  I missed that
when it went in.

--Dan

>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230317/a512f2fe/attachment.htm>