<div dir="ltr">Hi Magnus,<div><br></div><div>Follow up on your suggestion regarding contributing the minor JDK static build fixes/enhancements (branched from the hermetic Java discussion [1]). Since JEP 178 [2] has covered specification related issues already, we can create individual bugs/enhancements and PRs for the related changes on an as-needed basis. I've created JDK-8303796 [3] as a starting one. Will work with you and others on contributing our changes. Thank you!</div><div><br></div><div>[1] - <a href="https://mail.openjdk.org/pipermail/leyden-dev/2023-February/000119.html">https://mail.openjdk.org/pipermail/leyden-dev/2023-February/000119.html</a></div><div>[2] - <a href="https://openjdk.org/jeps/178">https://openjdk.org/jeps/178</a><br></div><div>[3] - <a href="https://bugs.openjdk.org/browse/JDK-8303796">https://bugs.openjdk.org/browse/JDK-8303796</a></div><div><br></div><div>Best,</div><div>Jiangli</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 14, 2023 at 12:55 AM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com">magnus.ihse.bursie@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>On 2023-02-14 00:52, Jiangli Zhou wrote:<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi Magnus,</div>
<div dir="ltr"><br>
</div>
<div>Thanks for the thoughts! Please see comments inlined below.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Feb 13, 2023 at 5:43
AM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com" target="_blank">magnus.ihse.bursie@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jiangli,<br>
<br>
On 2023-02-08 03:08, Jiangli Zhou wrote:<br>
> Hi Brian,<br>
><br>
> Here are the main buckets of the changes discovered in
JDK/VM to<br>
> support the proposed hermetic image:<br>
><br>
> 1) Resolve symbol conflicts to fully support JDK static
builds. Those<br>
> are mainly caused by duplicated symbols defined in
different native<br>
> libraries or VM code.<br>
><br>
> 2) Complete the built-in native library support in JDK.
For easier and<br>
> more reliable testing/release/deployment, we wanted to
support JDK<br>
> dynamic and static builds with the same set of object
files (.o).<br>
> We've changed to use unique names for<br>
>
JNI_OnLoad|JNI_OnUnload|Agent_OnLoad|Agent_OnUnload|Agent_OnAttach
in<br>
> different JDK JNI libraries by default. For both
dynamic linked and<br>
> static linked JDK builds, we use unique symbols for
JNI_OnLoad<br>
> function and friends. However, non-builtin application
JNI libraries<br>
> can still have the default JNI_OnLoad|... naming. We
still properly<br>
> support application JNI libraries using the default
JNI_OnLoad (and<br>
> friends) naming.<br>
><br>
> As we wanted to produce dynamic and static builds from
the same set of<br>
> object files, we've moved away from using the
STATIC_BUILD macro.<br>
><br>
> We've also done some makefile work to build both
dynamic shared<br>
> libraries (DSOs) and static libraries, within one JDK
build.<br>
<br>
This sounds like interesting work indeed. However, I am
inclined to <br>
agree with Andrew and wonder how much it relates to Project
Leyden. It <br>
might be that Leyden will need some kind of packaging story,
and that <br>
this can have a role to play in that. But it is not
immediately clear <br>
that it does fit in, and indeed, I think this is not one of
Leyden main <br>
problem areas at the time.<br>
<br>
But your code sounds very much interesting from a pure build
<br>
perspective! For at least this part of the code, I think you
should <br>
ignore Leyden for now, and just see if the static build
changes you have <br>
made could be fit for inclusion in OpenJDK.<br>
<br>
The static build part of the build system has been sadly
neglected due <br>
to resource limitations, for a long time. :( The rudimentary
system <br>
(actually, more like two separate systems) we have was put
in place <br>
mostly due to external requirements from Project Mobile and
the Graal <br>
integration, and was tacked on mostly as an after-thought.
It is not <br>
regularly tested, and I'd frankly be surprised if it
actually works <br>
right now. So I fully understand if you have been staying
away from <br>
STATIC_BUILD. :)<br>
<br>
It sounds like you have created a more dynamic system to be
able to <br>
select per library, if it should be compiled statically or
dynamically. <br>
Do I understand you correctly? If done correctly, it can
probably help <br>
bring a better abstraction to the build process.<br>
</blockquote>
<div><br>
</div>
<div>For JDK/hotspot natives, our experiment/prototype builds
all the JDK regular artifacts (e.g. lib/.../*.so) that the
existing JDK build produces. Additionally, it also creates
the JDK static libraries (e.g. lib_static/*.a) and a
bin/javastatic (with most of the needed JDK static libraries
statically linked into the launcher, for testing purposes
only, such as running jtreg tests) in the binary, as part of
the single JDK build. The hermetic image creation is done as
a post process, which takes the needed pre-built JDK static
libraries for linking into the final executable. The post
process is done outside the JDK build. The JDK runtime
support is enhanced to be able to support both built-in
libraries and dynamically loaded shared libraries. </div>
<div><br>
</div>
<div>It doesn't seem to be problematic to get the JDK static
support into OpenJDK first. It's especially helpful for you
or erikj@ to look at the makefiles changes and help massage
the changes according to the JDK build standard.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you are willing to contribute your work to OpenJDK, I
would <br>
definitely be interested in studying it in detail. </blockquote>
<div><br>
</div>
<div>Thanks!<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As you might be <br>
aware, contributions to OpenJDK must be done on the OpenJDK
<br>
infrastructure. One way to do this is to create a branch in
the sandbox <br>
repo[1], and push your changes there.<br>
</blockquote>
<div><br>
</div>
<div>Will get back to you on this, after some explorations on
open sourcing the changes.</div>
</div>
</div>
</blockquote>
<p>Let me know when you are done with that process.</p>
<p>/Magnus<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If it turns out to be of use for Project Leyden, all the
better if it is <br>
already in place. And if it turns out that this is
orthogonal to Project <br>
Leyden, I still think a cleanup in this area might be
beneficial for all <br>
of the JDK.<br>
</blockquote>
<div><br>
</div>
<div>All sounds good!</div>
<div><br>
</div>
<div>Best,</div>
<div>Jiangli</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
/Magnus<br>
<br>
[1] <a href="https://github.com/openjdk/jdk-sandbox" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk-sandbox</a><br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote></div>