version are you using now? Which framework are you using mainly? 0 10 20 30 40 50 Spring Boot Struts 2 Hibernate Quarkus Ktor Armeria React # of users 0 5 10 15 20 25 30 23 or later 21 17 11 8 6 or ealier # of users
over resident ones. Startup Latency Throughput Footprint Java apps running on application server △ ◎[1] ◎[1] ◦ Expectations from serverless container perspective ◎ ◎ ◎ ◎ [1] This is improved gradually over time.
compilation Not so highly optimized Not so better throughput C2 (a.k.a. server compiler) Longer time for compilation Highly optimized Better throughput
JDK 21 (21.0.4) GC : G1 Max heap : 75% allocation Application framework Micronaut 4.6.2 Option +UseStringDeduplication Other options might be specified in each case. Measurement Run 1000 times Average / Percentile (50, 90, 95, 99)
are improved since the number of classes to be loaded is decreased. Cautions A little bit efforts are required to create custom JRE (e.g., Multi-stage build to create container image). Note that jdeps sometimes does not find dependency modules like jdk.crypto.ec. From JDK 22, jdk.crypto.ec is included in java.base. Reduces JRE size only. Custom JRE
CDS (JEP 310 / JDK 10) Application Class Data Sharing (AppCDS) stores classes used by your applications in an archive file. (The java Command (oracle.com)) Default CDS (JEP 341 / JDK 12) Created at the JDK build time by running -Xshare:dump, using G1 GC and 128M Java heap (Oracle JDK / Class Data Sharing (oracle.com)) Dynamic CDS (JEP 350 / JDK 13) Dynamic CDS archive extends application class-data sharing (AppCDS) to allow dynamic archiving of classes when a Java application exits. (Class Data Sharing (oracle.com)) CDS Archive
Available in any platforms Can coexist Dynamic CDS and static CDS. Can also use CDS archives with custom JRE. Cautions As applications are updated, we must recreate CDS archive. CDS Archive
by default when CPU on the platform is multi-core processors or using 64-bit VMs. With just C1, there is no profiling overhead, so could we get better performance than with profiling enabled? According to some cloud vendors’ document, C1 is one of the options to improve startup time. Customize Java runtime startup behavior for Lambda functions - AWS Lambda (amazon.com) C1 only
As no profiling occurs, startup time will be reduced. Custom JRE, CDS archive, and this can be used together. Cautions This setting is not useful for long running applications, since such applications should leverage code generated by C2, which is highly optimized. C1 only
Lower memory footprint and other advantages. Cautions Hardware/Platform (CPU/OS) specific Longer build time A little bit effort is required for reflection support. Native Image
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 CRaC/CRIU
Startup time is quite short. Cautions Strictly same dependencies and environment between executions is required. Project is undergoing. Privileged operation is required. Some efforts to capture checkpoint (Automation is a key...) CRaC/CRIU
40.00% 60.00% 80.00% 100.00% JAR Extracted JAR jlink CDS CDS Combined C1 Native CraC Startup time ratio (Base=100, smaller is better) 99P 95P 90P 50P Average
time to peak performance, and footprint of Java programs. Focus Standardize AOT for Hotspot JVM Start native, but support and optimize dynamic stuff later Resources Project Leyden (openjdk.org)
known as training runs. Unified Cache Data Store (CDS) Archive Store class metadata, heap objects, profiling data, and compiled code. -XX:CacheDataStore Loaded Classes in CDS Archives Preload classes as soon as the application starts. -XX:+PreloadSharedClasses Method Profiles in CDS Archives Store method profiles from training runs in the CDS archive, allowing the Just-In-Time (JIT) compiler to start compiling earlier during warm-up. -XX:+RecordTraining -XX:+ReplayTraining AOT Resolution of Constant Pool Entries Resolve many constant pool entries during the training run, improving start-up times and enabling better code generation by the AOT compiler. -XX:+ArchiveFieldReferences -XX:+ArchiveMethodReferences -XX:+ArchiveInvokeDynamic
known as training runs. AOT Compilation of Java Methods Identify frequently used methods during the training run, compiles them, and stores them with the CDS archive. -XX:+StoreCachedCode -XX:+LoadCachedCode -XX:CachedCodeFile AOT Generation of Dynamic Proxies and Reflection Data Reduce start-up times by generating dynamic proxies and reflection data. -XX:+ArchiveDynamicProxies -XX:+ArchiveReflectionData Class Loader Lookup Cache Speed up repeated class lookups, which are common in application frameworks, by caching them. -XX:+ArchiveLoaderLookupCache
heap objects and profiling data harvested from the training run. <cds_file>.code The file contains AOT-compiled methods, optimized for the execution behaviors observed during the training run. [NOTE] Data in this file will be merged into <cds_file> in a future release.
20.00% 40.00% 60.00% 80.00% 100.00% JAR Extracted JAR jlink CDS CDS Combined C1 Native CraC Leyden Startup time ratio (Base=100, smaller is better) 99P 95P 90P 50P Average
Updating Java version is also another option. Several projects such as CRaC and Leyden to improve startup time are now on-going. Please note that we should choose the most suitable technique based on characteristics and requirements of applications.