[External] : Re: jmods-less jlinking prototype

[Dan Heidinga]

On Wed, Mar 15, 2023 at 8:36 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 15 Mar 2023, at 10:42, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> >
>
> > Reducing JDK's size is important and would in our opinion be worth some
> > extra complexity in jlink code. Why?
> >
> >   1. Allow recursive jlink runs (see above).
>
> I understand it’s an added capability. I’d like to understand why it’s
> important.
>

Read this in the context of previous discussions on this list.  In
particular, the previous Jlink thread between Severin, Brian, and myself
[0] where we discuss jlink as a proxy for the eventual Leyden condenser
tool.  With condensers, we're going to want to apply condensers and get a
runnable image.  We may also want to apply additional condensers to that
image and produce an even more condensed image.  The key idea here is the
output of the process (assuming it's non-terminal) needs to also be usable
as an input to the process:

{ JDK + modules | condensed image } --> condensers --> condensed image
condensed image --> runnable image

[0] https://mail.openjdk.org/pipermail/leyden-dev/2023-February/000133.html

>
> >   2. Installed JDK size is something everyone is paying a tax for,
> >      even though they might not even use jlink for their application
> >      needs.
>
> But if they don’t use jlink, the easier solution is to just delete the
> jmod files.
>

Sure.  One way to look at this is many existing deployments are "condensed"
already in that they've been opted into a single runnable platform (ie:
linux x86-64) and by allowing an image without jmods to be further jlinked,
we enable them to be condensed further.


>
> > For example installing the *full* JDK on Fedora or Red Hat
> >      Enterprise Linux by picking the 'java-17-openjdk-jmods' package,
> >      would have users download a whopping extra ~230MB of data.
>
> If size is that important you can get an even bigger reduction by not
> including debug info.
>
> >   3. Considering a cloud setup where a full JDK container image is
> >      being used to generate an application specific image including
> >      the Java runtime, such a JDK container image would have to
> >      include the jmods archives. The full JDK container image is an
> >      infrastructure component in such a setup. Even a ~80MB extra for
> >      such images results in extra money needing to be spent (for
> >      storage or network bandwidth).
>
> I still don’t understand. How many containers are used for building?
> Assuming a nice JDK build where jmods are 25%, we’re talking about a 25%
> difference in the bandwidth and storage for the *build* infra.
> How big of an impact is it?
>
> I think THIS is the main motivation here, and so more data about the
> impact is what’s required to assess the importance of the proposal.
>

Size reduction for existing installs is actually the nice-to-have benefit
we get by allowing a jlinked image to act as an input to jlink.  The core
benefit we care about for Leyden is being able to condense (jlink) an
already condensed (jlinked) runtime.



>
>
> > What's more, the size difference
> >      makes using the same JDK image for application runtime - yes some
> >      users want the full JDK in containers - as well as for the build-
> >      your-own-application-image jlink use-case uncompelling.
> >
>
> This one is really confusing to me. If you’re concerned with runtime size,
> with jlink you can reduce the size to 40MB in total; that’s a much, much
> bigger impact than removing the jmod files.
> So if size is important, jlink has a far bigger positive impact than a
> negative one, and a bigger positive impact than what you’re proposing —
> running jlink reduces the size by 85% as opposed to 25% —
> and if you don’t want to use jlink you can just delete the jmod files and
> be done with it.


Here I'm confused.  Severin has prototyped changes to make it easier to use
jlink for a broader set of consumers so of course we want to use jlink!
This is about making it easier to use jlink - to produce an initial image
and then to further condense that image.


>
>
> I understand that what you’re saying is that with a bit more complexity
> you can get the best of both worlds. It’s just that without more
> information about the impact, it’s unclear how significantly are both
> worlds better than just one world.
>

The high order bit in this approach is being able to use jlink to condense
a runtime image, and then use jlink to condense it further.  Do you have
concerns with the high order bit? We can talk about size benefits (a
secondary benefit) once we all agree on the high order bit.

--Dan


>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230315/99e93a1d/attachment.htm>