RFR: 8303796: Optionally build fully statically linked JDK image

Jiangli Zhou jiangli at openjdk.org
Sat Apr 29 00:11:53 UTC 2023


On Fri, 28 Apr 2023 18:14:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> 
> If I understand the make file changes proposed here, it runs the native linker to create "javastatic" with the launcher, libjvm and other JNI libs linked into one executable, this is generated and copied into the run-time image created by jlink.

For the testing/demo purpose (on static linking part) with this PR, the makefile changes in the PR only run the native linker step to perform static linking. The 'javastatic' is simply copied into the (regular) jlink'ed JDK image 'bin/' directory.  In our experiments/prototyping work, the 'javastatic' launcher binary is used along with the other artifacts from the regular JDK image (e.g. lib/modules)  for basic sanitary testing (running some of the jtreg tier 1 tests). The 'javastatic' is not used for creating the hermetic Java image. The post process building the hermetic image takes the .a files, lib/modules and other resources files as input.

>  I think this will need discussion as its more like an overlay. I think it is useful to have the build create the .a files as that's the first step towards putting them into packaged modules for producing static images.

Agreed. 

Based the initial feedback from you and other reviewers in the thread, I'll repurpose this PR for handling the .a part only. I'll split the 'javastatic' static linking part into a separate branch for needed discussions (including the potential JEP part). That branch can be on the sideline and it can be to verify/test the other static linking related changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1528259605



More information about the client-libs-dev mailing list