P3
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).
[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).