Overview

The primary goal of project Leyden is to improve startup and warmup of Java applications. It consists of series of JEPs and one of them is JEP 483. This JEP is about to introduce so called Ahead-of-Time cache. AOT cache is natural evolution of an old feature in the HotSpot JVM, class data sharing (CDS). The idea of AOT cache is to adopt AOT assets in Premain phase of HotSpot JVM. This in particular means to make the classes of an application instantly available, in a loaded and linked state, when the HotSpot Java Virtual Machine starts.

So, the HotSpot JVM is going to support an ahead-of-time cache which can store classes after reading, parsing, loading, and linking them. Once a cache is created for a specific application, it can be re-used in subsequent runs of that application to improve startup and warmup times.

As in case of CDS using AOT cache requires several steps:

1. First, create AOT configuration by running the application (training run)

   java -XX:AOTMode=record -XX:AOTConfiguration=app.classlist -cp app.jar App 

2. Second, create AOT cache

   java -XX:AOTMode=create -XX:AOTConfiguration=app.classlist -XX:AOTCache=app.aot -cp app.jar 

3. Finally, run the application with the AOT cache

   java -XX:AOTCache=app.aot -cp app.jar 

New functionality is disabled by default. This means that old CDS archive is created the same way as in previous JDK releases in case old CDS flags are using. New AOT cache is created/used in case new AOT flags are used. So, jdk24 will provide two ways to create/use CDS/AOT archive/cache:

• Using old CDS flags. In this case AOT class linking functionality is disabled by default. It can be enabled by setting AOTClassLinking flag.

  java -XX:DumpLoadedClassList=app.classlist -cp app.jar App java -Xshare:dump -XX:SharedClassListFile=app.classlist -XX:SharedArchiveFile=app.jsa -cp app.jar java -XX:SharedArchiveFile=app.jsa -cp app.jar App 

• Using new flags. AOT class linking functionality is also disable by default and needs to be enabled explicitly.

java -XX:AOTMode=record -XX:AOTConfiguration=app.classlist -cp app.jar App java -XX:AOTMode=create -XX:AOTConfiguration=app.classlist -XX:AOTCache=app.aot -cp app.jar java -XX:AOTCache=app.aot -cp app.jar 

Test Methodology

• Unit and functional testing

  • New unit tests to cover the new AOT command-line options to be developed by Dev team.
  • Existing CDS tests should continue to work to test current/old CDS functionality is not broken.
  • Existing CDS and application CDS tests is good primary source to test new AOT cache. We just need to run these CDS tests with -XX:+AOTClassLinking flag. Note, some CDS test cases might be incompatible with AOTClassLinking and needs to be filtered out.
  • It may require to develop more unit tests to cover functionality which is missed in existing CDS tests. Out of scope for jdk24/

• Stress/reliability testing Stress/reliability testing is important aspect of testing to test new features under stress. HotSpot testbase contains at least following types of stress tests:

  • Functional HotSpot stress tests (compiler/runtime/gc) We want to run some of these tests to test nothing is broken in case AOT cache is used. We will generate AOT cache and execute tests using this archive. For simplicity reasons we will create AOT cache which will only contains jdk classes (no test/application specific classes). Including test classes into AOT cache will most probably require jtreg modifications and is out of scope of this test plan. 
  • BigApps BigApps is ideal real case scenario to test AOT cache. BigApps framework need to be enhanced to implement new AOT running mode. This mode will do training run of the BigApp to create AOT cache and then second real run of the BigApp using that cache. Due to time constrains implementation of this mode is postponed for next jdk release. For jdk24 we will use AOT cache with jdk classes only.

• JCK testing

  • JCK conformance testing The JCK Team should provide the rules of conformance testing. Ideally AOT cache should be generated for every single automated test and then used to run the test with. This might require to introduce new JCK execution mode and also changes in test harness and tools like 'jck4jdk'. See more details here. The non-automated tests should be executed by IMT using this mode. Timeline - by Nov, at least  month before JDK 24 ATR.

  • JCK functional testing JCK runtime tests are regularly run as part of HotSpot CI/ATR testing. To avoid JCK failures to be found at the last stage of product testing we plan to add one more JCK configuration to run JCK runtime tests with AOT cache. The preliminary plan is to generate AOT cache for JDK classes only.

• Performance testing

  • As primary goal of AOT cache is to improve startup and warmup of Java application it might require developing/integration of new performance benchmarks.  Existing performance benchmarks needs to be run to guarantee there are no regressions. Performance/Dev teams are responsible for this.

Test inventory

Existing Tests

As mentioned in previous section existing Hotspot/JDK functional/stress tests are good candidates to run in JDK AOT cache mode ( AOT cache is built from jdk classes only). The following tests will be run in such mode:

• Hotspot tessts

  • runtime: compiler, gc, serviceability
  • Core libs: open/test/jdk
  • JCK automated testing
  • jckRuntimeTests - as is in CI
  • JCK testing using AOTed JCK

• Stress and load testing

  • all bigapps as in Ci
  • all bigapps with AOT jdk cache, 30min max

New Tests

• Unit tests to cover the new AOT command-line options.
• Unit tests to cover new AOT class linking functionality.
• AOT cache generation stress tests. Stress tests which tries to generate different AOT caches. Such tests could try to load numerous amount of classes with different topology/dependencies.  This test development is postponed to next jdk releases and is out of scope of jdk24.
• Run BigApps with AOT cache

Success Metrics

• no regressions in default configs (non AOT mode)
• no P1-P3 bugs
• All failed tests should be problem listed before the integration
• new code coverage (both java and native) 100% for new public API