Name of the profile that the JVM both reads from and writes to. Use of this flag is equivalent to using -XX:ProfileLogIn=<profilePath> -XX:ProfileLogOut=<profilePath>, and is the preferred way to specify profile names when different input and output names are not needed. If prefixed with cnc://, <profilePath> is used as the profile name in the CNC Profile Log Service. If not prefixed with cnc://, <profilePath> is interpreted as a file path on the JVM.
Using the Profile Log Service
Using ReadyNow involves two distinct phases:
-
Recording a good profile log that accurately captures the usage pattern you want to warm up. Recordings can be refined automatically through repetitive training cycles.
-
Using the profile log as the input to newly started VMs.
Using the CNC Profile Log Service to record and serve profile logs greatly simplifies the operational use of ReadyNow.
-
There is no need to configure any local storage for writing the profile log.
-
Cloud Native Compiler handles recording multiple profile candidates from multiple JVMs and promoting the best recorded profile log.
Creating and Writing To a New Profile Name
You use the CNC Profile Log Service by creating a connection to the CNC service and specifying the criteria for reading and writing profile logs. All of the necessary options can be specified as command-line arguments to the Java process at the time of deployment.
The basic lifecycle of using ReadyNow profile logs is as follows:
-
The JVM streams profile log output to the CNC service, giving the output a unique profile name.
-
Based on basic criteria specified in the command-line arguments, the JVM nominates the output profile log as a candidate for sharing with other JVMs.
-
The CNC service deals with candidate profile logs arriving from various JVMs that use the same profile name.
-
Whenever the service receives a request for a profile log with a given profile name, it examines the candidates it has collected and serves up the best one. This can change over time as the CNC service receives new and more complete profile log candidates.
-
JVMs can request multiple generations of a profile log. Rather than starting with no input profile log and recording its output log based on the regular JIT profiling process, the JVM can take a profile log as the input and further refine the profiling information, recording its experience as a new generation of that profile log. If you need to minimize the chances of having any deoptimizations through the life of your Java program, it is sometimes beneficial to record several generations. The CNC service always serves the newest generation for a profile name to JVMs. JVMs can cap the number of generations that they write out to avoid developing the profile forever.
Profile Log Service Commands
The following options are available in Azul Prime when using the Profile Log Service with CNC:
| Option | Description | Default |
|---|---|---|
-XX:CNCHost=host:port |
Address where CNC is listening. The default is localhost:50051. See Connecting a JVM to Cloud Native Compiler for how instructions on determining the correct host and port. |
null |
-XX:ProfileLogName=<profilePath> |
null |
|
-XX:ProfileLogOut=<profilePath> |
The ProfileLogOut enables Azul Zulu Prime JVM to record compilations from the current run. |
null |
-XX:ProfileLogIn=<profilePath> |
The ProfileLogIn allows Azul Zulu Prime JVM to base its decisions on the information from a previous run. The current ProfileLogIn file information will be read in its entirety - before Azul Zulu Prime JVM starts to create a new ProfileLogOut log. |
null |
-XX:ProfileLogOutNominationMinSize |
Indicate to server that the produced profile is eligible for promotion after specified amount of bytes recorded. 0 = any size eligible, -1 means it will never be promoted |
1m |
-XX:ProfileLogOutNominationMinTimeSec |
When used with Cloud Native Compiler, the minimum time, in seconds, a profile must record before CNC will nominate it as a candidate. 0 = any duration eligible, -1 means it will never be promoted |
120 |
-XX:ProfileLogOutMaxNominatedGenerationCount |
When used with Cloud Native Compiler, specifies the maximum generation of a profile that a VM will nominate. 0 = unlimited |
0 |
-XX:ProfileLogMaxSize=<value in bytes> |
Specifies the maximum size that a ReadyNow! profile log is allowed to reach. Profiles will be truncated at this size, regardless of whether the application has actually been completely warmed up. It is recommended to either not set this size explicitly, or set it generously if required, for example:
0 = unlimited |
0 |
-XX:ProfileLogTimeLimitSeconds=<value in seconds> |
Instructs ReadyNow to stop adding to the profile log after a period of N seconds regardless of where the application has been completely warmed up. It is recommended to either not set this size explicitly, or set it generously if required. 0 = unlimited |
0 |
-XX:ProfileLogDumpInputToFile=<name> |
Dump input profile to the specified path. For debugging purposes only. |
null |
-XX:ProfileLogDumpOutputToFile=<name> |
Dump output profile to the specified path. For debugging purposes only. |
null |
-XX:ProfileLogServiceConnectionTimeoutMillis |
Timeout on establishing remote connection and timeout on interval between downloading two chunks. Specified in milliseconds. |
5000 |
-XX:ProfileLogOutVerbose |
Enables logging of verbose, optional tracing information in |
true |
Substitution Macros
It is possible to use substitution macros in the profile path. Each macro unfolds to a 4-byte hash string taken from a particular plain-text string corresponding to a property:
| Macro | Description |
|---|---|
%classpathhash |
Hashed user-defined Java class path string |
%vmargshash |
Hashed JVM arguments string |
%vmflagshash |
Hashed JVM flags string |
%cmdlinehash |
Hashed string containing all plain-text values from above macros. Input values are concatenated to one string: Java class path string + JVM arguments string + JVM flags string. Afterwards, 4-bytes hash is applied to concatenated result. |
%jdkver |
Hashed JDK version number converted to string |
%jvmver |
Hashed JVM version number converted to string |
Basic Profile Recording with Server Defaults
In its most basic form, you just let the server-side defaults do all the work. By default, CNC will nominate profile logs after three full generations and does not place a limit on log size. Suppose you want to record a new profile while deploying code to a fleet running in production. Run with the following options:
java -XX:CNCHost=TestEnvCncHost \
-XX:ProfileLogName=cnc://MyApp-v3 \
-jar myapp.jar
In this case, all JVMs nominate their logs for promotion after two minutes of recording and keep recording until the JVM shuts down. For best results, do a test run in a canary instance for at least two minutes and if possible a full ten minutes. This creates generation 1 of your profile. Then restart your fleet as normal. As JVMs start up, they receive a profile from CNC and check the generation number. If that number is less than the server-side default maximum of 3, the JVM writes out the next generation of the profile. Once there is a valid generation 3 of the profile on CNC, none of the JVMs write any more output.
Capping Profile Log Recording and Maximum Generations
We can make our example above more complex:
-
A profile needs to record for at least 2 minutes to be nominated.
-
After 10 minutes you want to stop recording.
-
You want to record two generations of the profile.
Start your JVM with the following parameters:
java -XX:CNCHost=TestEnvCncHost \
-XX:ProfileLogName=cnc://MyApp-v3 \
-XX:ProfileLogTimeLimitSeconds=600 \
-XX:ProfileLogOutMaxNominatedGenerationCount=2 \
-jar myapp.jar
Using a Previous Profile as the Basis of a New Profile Recording
When you’re deploying version 3 of MyApp, you often have a valid profile for version 2. In most cases, you change a small portion of your code between versions and most of the previous profile is still valid for your new version. When you feed in the previous version of the profile as input to recording the new version of the profile, you can in most cases eliminate the need to do multiple training iterations.
Using our above example, perform one run of the full ten minutes in a canary with the following settings:
java -XX:CNCHost=TestEnvCncHost \
-XX:ProfileLogIn=cnc://MyApp-v2 \
-XX:ProfileLogOut=cnc://MyApp-v3 \
-XX:ProfileLogTimeLimitSeconds=600 \
-XX:ProfileLogOutMaxNominatedGenerationCount=1 \
-jar myapp.jar
To restart the rest of your fleet with the following settings:
java -XX:CNCHost=TestEnvCncHost \
-XX:ProfileLogName=cnc://MyApp-v3 \
-XX:ProfileLogTimeLimitSeconds=600 \
-XX:ProfileLogOutMaxNominatedGenerationCount=1 \
-jar myapp.jar