Summary

The default behavior of AOT caches is expanded by adding new AOT optimizations, which are enabled by default. New flags control those optimizations, when such further control is desired.

Such optimizations may be enabled in a granular manner by use of diagnostic switches or product switches. Normally, HotSpot applies all available optimizations, expecting users to disable them only to assist in diagnosing bugs or performance artifacts. Some high-risk optimizations may be off by default, and have a flag that users may use to opt into them.

In this case, adding profile data to the AOT cache seems low-risk. It helps application warmup consistently, and it adds only a modest overhead (<10%) to AOT cache size.

Specification

-XX:+AOTRecordTraining (diagnostic, on by default). Applies only in training (AOTMode=record, possibly selected from AOTMode=auto). When it is true during training runs, selected profile data is collected into the AOT configuration output file, to be stored eventually in the AOT cache.

-XX:+AOTReplayTraining (diagnostic, on by default). Applies only in AOT cache creation and production runs (AOTMode=create or AOTMode=on, possibly selected from AOTMode=auto). When it is true during a production run using an AOTCache that contains stored profiles, use those profiles to assist in JIT activities. Otherwise ignore them. When it is true during AOT cache creation, copy any profiles from the AOT configuration into the AOT cache.

-XX:-AOTPrintTrainingInfo (diagnostic, off by default). Print additional information about training activity (AOTMode=record).

-XX:-AOTVerifyTrainingData (diagnostic, off by default). Perform ad hoc verifications of training data stored in the AOT cache.

-XX:-AOTCompileEagerly (diagnostic, off by default). Applies only in production runs. Optional "knob" to control JIT queueing policy as it interacts with AOT profiles. The effect is to queue JIT tasks, not only as methods warm up, but also as classes are initialized (if such classes have AOT records that indicate compilations will eventually occur). Sometimes this helps warmup. JIT queueing policy is tuned from release to release transparently to users. This flag may become obsolete if a more robust policy is discovered.

Judging from the work title (Ahead-of-Time Method Profiling) it would seem that these options should use the word "profiles" instead of "training". In reality, the AOT cache contains not only profile data per se but other associated data called "training data", which may be readily seen in the JVM source code. As a simplified story, we speak (sometimes vaguely) of profiles, and we actually mean more kinds of profiles than just method profiles. The JIT keeps logs of some of its optimization decisions (in response to profiles and other behavioral data) which are stored in the training data as well. One might say that the JIT "profiles itself" by recording summaries of past optimization decisions, so as to prompt similar decisions in production. As a matter of implementation precision, we refer to all such profile-like data as "training data", which is the data which comes from a training run.

The AOT code JEP adds code to this mix; the code is compiled during AOT cache creation time, using the training data (profiles plus JIT logs plus other miscellaneous information). In this way, the forthcoming AOT code JEP will depend on this "profiling" JEP, because of its heavy reliance on training data. As an editorial decision, we wrote the JEPs to keep these implementation details "below the fold".