This deck was created for Java Developers Summit Online 2023, hosted by Oracle Japan.
All contents in this deck are in English but I provide the presentation is in Japanese.
J Startup Latency Throughput Footprint Remarks △ ◦à◎ ◦à◎ ◦ No need to worry startup in case of applications resided on application server. Requirements for serverless applications and autoscaling containers Characteristics of typical Java applications Startup Latency Throughput Footprint Remarks !!! !! !! !! In case of short-live applications, startup time is much more important.
Load and Initialize • Generate bytecode templates JVM • Load application classes • Initialize application classes • Application specific initialization JVM • Compile/deoptimize/recompile Application • Process specific workloads JVM Startup Application Startup Application Warmup 1st operation 2nd operation or later Fast Quick Long time
in Java 8. C1 (a.k.a. client compiler) Shorter time to compile Not so highly optimized Not so better throughput C2 (a.k.a. server compiler) Longer time to compile Highly optimized Better throughput
will be removed in the future release. [JDK-8218003] Release Note: Deprecated Java Options -Xverify:none and -noverify - Java Bug System (openjdk.org) For users who need to run without startup verification AppCDS allows you to archive their classes. The classes are verified during archiving and avoid verification at runtime.
and memory footprint are improved since the number of classes to be loaded is decreased. Drawbacks A little bit efforts are required to create custom JRE. Multi-stage build to create container images Note that jdeps sometimes does not find dependency modules like jdk.crypto.ec.
CDS was introduced in 8u40. Default CDS (JEP 341 / JDK 12) App CDS (JEP 310 / JDK 10) Dynamic CDS (JEP 350 / JDK 13) Some distributions don't include default CDS archive. e.g. Microsoft Build of OpenJDK Release Notes for the Microsoft Build of OpenJDK | Microsoft Learn
an application # Create Dynamic CDS archive at exiting application $ java -XX:ArchiveClassesAtExit=<Archive> -jar App.jar # Use the CDS archive with application $ java -XX:SharedArchiveFile=<Archive> -jar App.jar CDS archive and custom JRE can be used together.
to load classes. Available in any platforms Dynamic CDS and custom JRE can be used together. Drawbacks As the application is updated, CDS archive should be created.
CPU on the platform is multi-core processors or using 64-bit VMs. If choosing to use only C1, There is no profiling overhead. You will get better performance than if profiling is enabled.
can gain benefits. As no profiling occurs, startup time will be reduced. Custom JRE, CDS archive, and this can be used together. Drawbacks This setting is not useful for long running applications, since such applications should leverage generated code by C2, which is highly optimized.
Lower memory footprint Drawbacks Hardware/Platform (CPU/OS) specific Long compilation time Generated executable is bigger than the original jar file. not suitable for long running (as of now). A little bit effort is required for reflection support.
environment and generated codes returned from JIT compilation environment are used in runtime environment, would performance be improved? Distributed JIT OpenJ9 JITServer (Eclipse OpenJ9) IBM Semeru Runtime - Resources and Tools - IBM Developer - IBM Developer Azul Cloud Native Compiler Java Compilation in the Cloud | Cloud Native Compiler (azul.com)
instance. Each JVM instance communicates with the JIT JVM instance. VM or Containers VM or Containers VM or Containers VM or Containers VM or Containers VM or Containers Java Application JVM JIT Compilation JIT Server or Cloud Native Compiler Service JIT Compilation Request compilation à ß Return generated codes
could run on smaller resources. Especially useful for apps running on containers. JIT compilation might be faster (depending upon circumstances). Drawbacks Network latency Maybe not suitable for super short- live applications Not standardized yet OpenJ9 Azul Cloud Native Compiler
in interpreter (and/or C1) phase. If we can take snapshots and persist them in storages to restore, C2 generated hot codes might provide high performance.
java hot methods at application startup (openjdk.org) Azul ReadyNow! / Compile Stashing (Azul) ReadyNow!® - Azul | Better Java Performance, Superior Java Support Using Compile Stashing (azul.com) CRaC (Coordinated Restore at Checkpoint) Based on CRIU (Checkpoint/Restore In Userspace). Azul Provides the CRaC in AWS SnapStart Builds | Foojay.io (Java 11 based) Dynamic AOT / CRIU support (OpenJ9) Fast JVM startup with OpenJ9 CRIU Support – Eclipse OpenJ9 Blog
creates the checkpoint only if the whole Java instance state can be stored in the image. Resources like open files or sockets are cannot, so it is required to release them when checkpoint is made. CRaC emits notifications for an application to prepare for the checkpoint and return to operating state after restore.” https://github.com/CRaC/docs
codes are available whenever the application starts. Startup time is almost the same as AOT case. Drawbacks Platform dependencies Not standardized yet Require persistent storage The same dependencies and environment between runs. Some efforts to capture checkpoint (Development framework would cover them in future…)
to peak performance, and footprint of Java programs. Focus Standardize AOT for Hotspot JVM Start native, but support and optimize dynamic stuff later
Java-related GraalVM tech and help to prepare the JDK community for potential incubation into the main release in the future. Focus Contributing the latest version of the GraalVM just-in-time (JIT) compiler and integrating it as an alternative to the existing JIT compiler of the HotSpot VM. Bring in the necessary ahead-of-time (AOT) compilation technology to make this new JIT compiler written in Java available instantly on JVM start. Galahad will pay close attention to Leyden and track the Leyden specification as it evolves.