<div dir="ltr"><div dir="ltr">Hi Andrew,</div><div dir="ltr"><br></div><div>Thanks for bringing up the question! :-)</div><div><br></div><div>Currently, the hermetic Java investigation has not done any of the startup/runtime performance or footprint reduction related work. We have only investigated the static image packaging and formatting (also mentioned in the response to Brian's email). Our experiments in real world production environments have found that a single executable image can meet the existing production requirements (for cases that we have tested with) and simplifies configurations/deployments without a separate JDK binary. We would like to share the work with the community early, to find out if we are in the right direction. With hermetic Java image, it has the capability for including pre-digested (e.g. pre-loaded class data and archived heap data in CDS and potentially pre-compiled code) data in a single executable. Hopefully the packaging/formatting investigation may help accelerate some of Leyden's progress. </div><div><br></div><div>Best regards,</div><div>Jiangli</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 2, 2023 at 9:31 AM Andrew Dinn <<a href="mailto:adinn@redhat.com">adinn@redhat.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>
Thanks for pointing the project at this work.<br>
<br>
Your presentation (rightly) describes Leyden's goals as addressing:<br>
<br>
   Slow startup time<br>
   Slow time to reach runtime peak performance<br>
   Large footprint<br>
<br>
I'm not clear to what degree 'Hermetic Java' helps with any of those. <br>
Can you comment and, perhaps, provide some numbers?<br>
<br>
regards,<br>
<br>
<br>
Andrew Dinn<br>
-----------<br>
<br>
On 02/02/2023 16:13, Jiangli Zhou wrote:<br>
> (Resending in plain text formatting)<br>
> <br>
> Hi,<br>
> <br>
> During the last one and a half years, Google has done some extensive <br>
> research on linux-x64 with Java static image, as project Hermetic Java <br>
> [1]. We would like to share our experiences/results with the community <br>
> and present our approach for discussion under the Leyden project. We <br>
> hope to contribute the work to OpenJDK through project Leyden, via the <br>
> JEP [2] process as needed.<br>
> <br>
> With Hermetic Java, our main goal is to create a single executable image <br>
> including the Java runtime environment, Java application and the <br>
> dependencies. This addresses some real-world Java deployment issues and <br>
> challenges that we have encountered over the years.  We believe it fits <br>
> 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 <br>
> 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 <br>
> components including the Hotspot VM, runtime JIT compiler (C1, C2), CDS, <br>
> etc.<br>
> <br>
> Our focus has been on the image packaging and formatting part. This <br>
> works roughly as follows:<br>
> <br>
> 1. The executable image (see slide #10 of [1]) consists of three <br>
> sections: the ELF executable section (see slide #14), the JDK runtime <br>
> 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 <br>
> launcher executable, which allows the image to work as a native <br>
> executable. The JDK runtime section contains the JDK lib/modules image <br>
> starting at a page-aligned file offset. This section can include other <br>
> data that requires special alignment, such as the CDS archive. The JAR <br>
> section holds the Java application classes, dependent library classes, <br>
> and resources. JDK runtime resource files, such as java.security and <br>
> java.policy are also packaged within the JAR section.<br>
> <br>
> 2. The Java launcher executable is statically linked with Hotspot/JDK <br>
> natives and application JNI natives (see slide #15 - #18).<br>
> <br>
> For static native library support, we enhance and complete existing <br>
> OpenJDK work [3, 4, 5]. It provides a flexible solution for loading <br>
> built-in (static) native libraries while still allowing dynamically <br>
> loading shared JNI libraries (if desired).<br>
> <br>
> 3. With a single executable image, we define the image file path as the <br>
> java.home (see slide #23). A JavaHome class is used to provide uniform <br>
> APIs for accessing JDK resources in traditional and Hermetic Java <br>
> (single image) execution modes.<br>
> <br>
> Hermetic Java is an accumulation of wisdom that Google obtained from <br>
> real-world production deployments over many years (years before the <br>
> current project research/experiments). We would love to gather feedback <br>
> from community members. Any input and feedback are welcome and appreciated!<br>
> <br>
> We are happy to provide additional information and answer questions <br>
> (open to discussions in any form).<br>
> <br>
> [1] <a href="http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf</a> <br>
> <<a href="http://cr.openjdk.java.net/~jiangli/hermetic_java.pdf" rel="noreferrer" 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" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html</a> <br>
> <<a href="http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8005716</a> <br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8005716" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8005716</a>><br>
> <br>
> [4] <a href="https://bugs.openjdk.org/browse/JDK-8136556" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8136556</a> <br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8136556" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8136556</a>><br>
> <br>
> [5] <a href="https://bugs.openjdk.org/browse/JDK-8232748" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8232748</a> <br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8232748" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8232748</a>><br>
> <br>
> Best regards,<br>
> <br>
> Jiangli<br>
<br>
</blockquote></div></div>