(TODO: this is the "binary AOT config" we discussion in Leyden meetings, to be done before AOT Profile JEP).

Currently, in the premain branch, if you want to store profiling data and compiled code into the AOTCache, you need to use the -XX:CacheDataStore option. There are two issues with this option:

[1] It's naming is inconsistent with the -XX:AOT family of flags that we are planning for Leyden-related features.

[2] The assembly phase is executed automatically at the end of the training run. In some cases, it may be desirable to perform the assembly separately at a later time (or even on a different host).

Proposal
=======
The handling of profiling data and compiled code should be supported by the workflow as described in JDK-8315737 (JEP 483: Ahead-of-Time Class Loading & Linking)

(1) training run
$ java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf \
       -cp app.jar com.example.App ...

(2) AOT cache assembly
$ java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf \
       -XX:AOTCache=app.aot

With JDK-8315737, step (1) writes app.aotconf as a text file. However, the profiling data is difficult to be represented as text data.

The proposal is: when step (1) is executed, and the VM is configured to record profiling data (with -XX:+RecordTraining), binary data will be written into app.aotconf. This data is essentially a partial AOT cache, where class metadata and profiling data are store as images of C++ objects that have direct pointers to each other. (Note: this file is the same as the "preimage" generated when you use the -XX:CacheDataStore option.)

In step (2), when -XX:AOTConfiguration points to a valid binary file that contains class metadata and profiling data, we create the production AOTCache, which contains class metadata, heap data, profiling data and compiled methods. (Note: this does the same thing as with the -XX:CDSPreimage option in premain).