jmods-less jlinking prototype

[Alan Bateman]

On 15/06/2023 09:50, Severin Gehwolf wrote:
> :
> 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.

I think a nice property to have would be for a jlink command without 
packaged modules generate an identical run-time image as it would with 
the same command when using the packaged modules. In my view at least, 
if it can't guarantee to generate the same run-time image then it should 
fail. I can't tell how close you are to this but it means being able to 
reconstitute the original resources or detect that they have changed. So 
I think it means plugins to un-do transformations where feasible, maybe 
hashes to detect changes to resources. If we had that they I think it 
would be a useful change to have in the main line. Clearly if there is 
stripping of native debug symbols, and some other transformations, then 
you aren't going to be able to reconstitute the original natives with 
debug info. So if someone were to create a run-image with stripping and 
including jdk.jlink module then the resulting run-image could not be 
used to stamp down further run-images without specifying the location of 
the packaged modules.

I'm less sure about connection to Leyden and condensers.

-Alan