jmods-less jlinking prototype

[Severin Gehwolf]

Hi Alan,

On Wed, 2023-03-15 at 14:51 +0000, Alan Bateman wrote:
> > > > The Problem:
> > > > ------------
> > > > Why do we need the 'jmods' directory when running jlink when 'java --
> > > > list-modules' lists all the modules and all the files from the JDK
> > > > build are in <install/location/of/jdk> (only 'jmods' directory is
> > > > missing)[1]?
> > 
> > Just some history around this. During JDK 9, there was a suggestion that 
> > the packaged modules should be a separate download but that had its own 
> > set of issues.  There were also suggestions that jlink should use the
> > classes/resources from the current run-time image to avoid needing to
> > include the complete contents of all packaged modules, it just wasn't
> > interesting to pursue at the time. That was 6+ years ago and there is a 
> > lot of experience with jlink since then, plus we've now on a road where 
> > jlink may be working with condensers in the future. So it could be 
> > interesting to explore to see how it might fit in.
> > 
> > More background is that generating a run-time image may involve a number 
> > of transformations, e.g jlink --strip-debug may remove debugging symbols 
> > and strip debug related class file attributes, other plugins, like 
> > generate-jli-classes and system-modules, generate code and/or modify a 
> > number of classes.  Post generation, there may also be changes to 
> > configuration files in conf/**. I think the point is that all types of 
> > resources (native libs, executables, classes/resources, conf) can be 
> > filtered out, stripped, or irreversibly transformed. Even if the 
> > run-time image has the jdk.jlink module, it might not have many of the 
> > modules that were in the original JDK builds so it's not really a good 
> > starting point for stamping out further images.

Of course the starting point needs to be suitable for the individual
use-cases.

> > On container environments, we see a lot of examples where jlink is run 
> > to produce a run-time image with a subset of the modules and with some 
> > stripping and compression to get a smaller run-time image. Smaller 
> > container means faster to transport across network and deploy, great!
> > Most of the recipes that I've seen published don't allow for further 
> > jlink-ing, either because they only have a small subset of the modules 
> > or they don't have the jdk.jlink module so they don't have the tool. 
> > Maybe this effort might change that.

Exactly!

> > So I think it could be interesting to explore to at least see how far it 
> > can get.

I'd like to restart this conversation in order to ultimately arrive at
a go/no-go decision about this patch. Hope that's OK.

We do agree it's interesting to explore further. Since last time we
spoke the patch has been improved further and I think it's viable. It
supports the three main platforms and passes the basic jtreg testing
(including the added test; see below for the GHA runs). So if we were
to contribute this into a shared repo, which one should this go? a)
openjdk/jdk (a.k.a JDK mainline) or b) leyden/jdk c) something else?
Would you have any thoughts as to which repo would be most suitable at
this point to discuss a PR?

We are reasonably confident that it works well for a majority of use-
cases (also outside of leyden) so it might be useful to have in
mainline JDK. But maybe it makes sense to first add it to leyden? I'm
not sure. In the leyden context it would be a great first building
block to further explore composability with a simple enough patch[1].
Consider:

j_A -> j_B -> j_C -> j_D

where j_A is a full jlink from jmods (produced during the OpenJDK
build), and then j_B..j_D would be further reductions (condensor runs
if you will).

Happy to document the caveats of this new jmod-less mode in a CSR if
that helps. IMHO, there aren't that many in practice.

Thanks,
Severin

[1] https://github.com/jerboaa/jdk/compare/jlink-jmods-base...jerboaa:jdk:jlink-jmods-less?expand=1
    jdk/tools/jlink tests, see 'jdk/jlink' test runs:
    Before: https://github.com/jerboaa/jdk/actions/runs/5266908852
    After:  https://github.com/jerboaa/jdk/actions/runs/5269856679