-
Enhancement
-
Resolution: Unresolved
-
P4
-
26
-
generic
-
generic
Currently there is no simple way for users to 1) fully list the contents of an AOT Cache, nor to determine how that content 2) is selected during a training run, 3) generated during a cache assembly run or 4) consumed during a production run.
The JVM's logging system provides some of the required information but does not do so in a manner that makes it easy to perform any of the above 4 tasks. This issue is best addressed by systematizing and enhancing the JVM's existing AOT logging output to present a complete and coherent set of messages that will allow one or more external log analysis tools to provide the required summary information and, in addition, enable details to be selected, viewed and browsed.
The above solution is recommended for several reasons. Firstly, it piggy-backs on an existing JVM logging capability to enable the relevant information to be generated and collected, rather than requiring some new mechanism to be added. Secondly, use of the logging mechanism retains a close connection between the code that operates on the cache and the logging code that records that operation, making it easier to maintain a correct view of the AOT cache. Finally, it decouples the tools which process the log output from the JVM and JDK code base, allowing them to employ Java technologies outside the JDK that the JVM should not depend on.
This umbrella JIRA tracks the various enhancements required in order to achieve the above goals
The JVM's logging system provides some of the required information but does not do so in a manner that makes it easy to perform any of the above 4 tasks. This issue is best addressed by systematizing and enhancing the JVM's existing AOT logging output to present a complete and coherent set of messages that will allow one or more external log analysis tools to provide the required summary information and, in addition, enable details to be selected, viewed and browsed.
The above solution is recommended for several reasons. Firstly, it piggy-backs on an existing JVM logging capability to enable the relevant information to be generated and collected, rather than requiring some new mechanism to be added. Secondly, use of the logging mechanism retains a close connection between the code that operates on the cache and the logging code that records that operation, making it easier to maintain a correct view of the AOT cache. Finally, it decouples the tools which process the log output from the JVM and JDK code base, allowing them to employ Java technologies outside the JDK that the JVM should not depend on.
This umbrella JIRA tracks the various enhancements required in order to achieve the above goals
1.
|
Upgrade AOT map file logging to display more assets and asset content |
|
Open | María Arias de Reyna Domínguez | |
2.
|
Upgrade AOT Cache logging to identify assets and operations with common tags, keywords and formats |
|
Open | Unassigned | |
3.
|
Support browsing of AOT Cache content via tooling that analyzes map output |
|
Open | Unassigned | |
4.
|
Ensure JFR and profilers can identify AOT compiled code |
|
New | Unassigned | |
5.
|
Help users to control selection of Training Data assets |
|
Open | Unassigned | |
6.
|
Generate Heap Dump immediately after loading AOT heap image |
|
New | Unassigned | |
7.
|
Use -Xlog:aot+map to print contents of existing AOT cache |
|
Open | Unassigned |