<div dir="ltr"><div dir="ltr">Hi Brian,</div><div dir="ltr"><br></div><div>Thanks for the response!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 2, 2023 at 9:16 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@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>
<font size="4"><font face="monospace">Thanks for sharing this
information! <br>
<br>
As far as I understand it, this is a _packaging mechanism_ to
take a combination of JDK, application classfiles and resources,
and native libraries, and combine them into a single executable,
and the benefits of this include "one file to distribute" and
"can't run the app on the wrong JDK". Further, the system
classloader has been modified to load classes out of the image
rather than from the file system. <br>
<br>
My question is about your relationship to the "closed world"
assumption (and the optimizations that can derive from it); I am
unsure of whether you make any closed-world assumptions in your
current approach? Is there any reason why classes cannot be
loaded dynamically, `invokedynamic` sites can't be linked
dynamically, etc? Secondarily, does your current implementation
perform any optimizations related to faster startup and warmup?
<br>
<br>
My assumption is that the answer is "no restrictions on
dynamism, no specific optimizations for startup/warmup, it's
purely a packaging mechanism", combined with a reminder that the
sorts of optimizations that have been explored elsewhere (Native
Image, CraC, SnapStart) could equally well be combined with your
packaging approach.<br>
<br>
Do I have it right?<br></font></font></div></blockquote><div><br></div><div>You are right in the above. :-) In our current investigation/work, we don't apply any restrictions on loading classes and JNI native libraries. When desired, it can still dynamically load classes and native libraries from outside the image. With a hermetic Java image, our usages (at least all the cases that we have experimented with so far) do not require such flexibility. In those cases, closed world assumptions could be applied. We haven't done any optimization related work yet, beyond the packaging/formatting itself. We hope the hermetic Java image solution can be a vessel to faciality those sorts of optimizations.</div><div><br></div><div>Best regards,</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"><div><font size="4"><font face="monospace">
<br>
Cheers,<br>
-Brian<br>
<br>
<br>
</font></font><br>
<div>On 2/2/2023 11:13 AM, Jiangli Zhou
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">(Resending in plain text formatting)<br>
<br>
Hi,<br>
<br>
During the last one and a half years, Google has done some
extensive research on linux-x64 with Java static image, as
project Hermetic Java [1]. We would like to share our
experiences/results with the community and present our approach
for discussion under the Leyden project. We hope to contribute
the work to OpenJDK through project Leyden, via the JEP [2]
process as needed.<br>
<br>
With Hermetic Java, our main goal is to create a single
executable image including the Java runtime environment, Java
application and the dependencies. This addresses some real-world
Java deployment issues and challenges that we have encountered
over the years. We believe it fits very well with the overall
goal of project Leyden in the following aspects:<br>
<br>
- Provide a build-time created static image derived from an
application and JDK; Image executes as a standalone program.<br>
- Satisfy closed-world constraints.<br>
- Is built on top of OpenJDK and can utilize existing OpenJDK
components including the Hotspot VM, runtime JIT compiler (C1,
C2), CDS, etc.<br>
<br>
Our focus has been on the image packaging and formatting part.
This works roughly as follows:<br>
<br>
1. The executable image (see slide #10 of [1]) consists of three
sections: the ELF executable section (see slide #14), the JDK
runtime section (see slide #20, #21) and the JAR section (see
slide #22). <br>
<br>
The ELF section is at the beginning of the image and contains
the Java launcher executable, which allows the image to work as
a native executable. The JDK runtime section contains the JDK
lib/modules image starting at a page-aligned file offset. This
section can include other data that requires special alignment,
such as the CDS archive. The JAR section holds the Java
application classes, dependent library classes, and resources.
JDK runtime resource files, such as java.security and
java.policy are also packaged within the JAR section.<br>
<br>
2. The Java launcher executable is statically linked with
Hotspot/JDK natives and application JNI natives (see slide #15 -
#18).<br>
<br>
For static native library support, we enhance and complete
existing OpenJDK work [3, 4, 5]. It provides a flexible solution
for loading built-in (static) native libraries while still
allowing dynamically loading shared JNI libraries (if desired).<br>
<br>
3. With a single executable image, we define the image file path
as the java.home (see slide #23). A JavaHome class is used to
provide uniform APIs for accessing JDK resources in traditional
and Hermetic Java (single image) execution modes.<br>
<br>
Hermetic Java is an accumulation of wisdom that Google obtained
from real-world production deployments over many years (years
before the current project research/experiments). We would love
to gather feedback from community members. Any input and
feedback are welcome and appreciated!<br>
<br>
We are happy to provide additional information and answer
questions (open to discussions in any form).<br>
<br>
[1] <a href="http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf" target="_blank">http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf</a><br>
<br>
[2] <a href="http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html" target="_blank">http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html</a><br>
<br>
[3] <a href="https://bugs.openjdk.org/browse/JDK-8005716" target="_blank">https://bugs.openjdk.org/browse/JDK-8005716</a><br>
<br>
[4] <a href="https://bugs.openjdk.org/browse/JDK-8136556" target="_blank">https://bugs.openjdk.org/browse/JDK-8136556</a><br>
<br>
[5] <a href="https://bugs.openjdk.org/browse/JDK-8232748" target="_blank">https://bugs.openjdk.org/browse/JDK-8232748</a><br>
<br>
Best regards,<br>
<br>
Jiangli</div>
</blockquote>
<br>
</div>
</blockquote></div></div>