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 Optimizer Hub ReadyNow Orchestrator 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.
JVMs provide profile logs, outputting them to Optimizer Hub ReadyNow Orchestrator on an ongoing basis as the JVM experience evolves.
JVMs designate a set of criteria for nominating their individual profile logs as candidates for promotion with criteria chosen by the JVM that are configurable, with some defaults.
ReadyNow Orchestrator handles recording multiple profile candidates from multiple JVMs and promoting the best recorded profile log.
The ReadyNow Orchestrator considers all provided logs that meet their specific JVM’s nomination criteria and meet the ReadyNow Orchestrator’s own promotion criteria that are configurable, with some defaults.
You no longer need to manually prepare a profile and then distribute it before rolling out new versions of your code. Instead, you can generate the profile automatically in production as part of your fleet restart.
Within the qualifying candidates (eligible for nomination and promotion, per criteria), Optimizer Hub ReadyNow Orchestrator picks a specific log as the “currently prompted” profile log, based on rules for picking the promoted log from within the qualifying candidates are. For example, the longest qualifying profile log in the largest generation.
When a JVM connects to the Optimizer Hub ReadyNow Orchestrator service with a profile name, it is provided with the currently promoted profile log (if one exists with that profile name) as an input.
ReadyNow Orchestrator monitors the optimization profiles of an entire fleet of JVMs rather than just one JVM, intelligently picking the best one.
You use ReadyNow Orchestrator by creating a connection to the Optimizer Hub 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 ReadyNow Orchestrator, 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.
ReadyNow Orchestrator 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 ReadyNow Orchestrator 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. ReadyNow Orchestrator 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.
The following options are available in Azul Prime when using ReadyNow Orchestrator with Optimizer Hub:
| Command Line Option | Description | Default | ||
|---|---|---|---|---|
-XX:OptHubHost=<host>:<port> |
|
null |
||
-XX:ProfileName=<value> |
Name of the profile to identify the application and its version, for example, The ProfileName may only contain alphanumeric characters, and |
null |
||
-XX:[+/-]EnableRNO |
Enables ReadyNow read and write to ReadyNow Orchestrator. Requires |
|
||
The ProfileLogOut enables Zing to record compilations from the current run.
|
null |
|||
-XX:ProfileLogIn=<value> |
The ProfileLogIn allows Zing to base its decisions on the information from a previous run. The current ProfileLogIn file information is read in its entirety - before Zing starts to create a new ProfileLogOut log.
|
null |
||
-XX:ProfileLogOutNominationMinSize [1]"For more information."] |
Indicate to server that the produced profile is eligible for promotion after specified amount of bytes recorded.
|
1M |
||
-XX:ProfileLogOutNominationMinSizePerGeneration [1]"For more information |
Define minimum acceptable amount of bytes per generation which the profile size should reach to become eligible for promotion. List of pair <generation>:<size>, separated by |
null |
||
-XX:ProfileLogOutNominationMinTimeSec [1]"For more information |
When used with ReadyNow Orchestrator, the minimum time, in seconds, a profile must record before ReadyNow Orchestrator can nominate it as a candidate.
|
120 |
||
-XX:ProfileLogOutNominationMinTimeSecPerGeneration [1]"For more information |
When used with ReadyNow Orchestrator, the minimum time, in seconds, per generation during which the profile should be recorded in order to become eligible for promotion. List of pair <generation>:<duration>, separated by |
null |
||
-XX:ProfileLogOutMaxNominatedGenerationCount [1]"For more information |
When used with ReadyNow Orchestrator, specifies the maximum generation of a profile that a VM nominates. This parameter has a server-side counterpart
|
0 |
||
-XX:ProfileLogMaxSize=<value in bytes> [1]"For more information |
Specifies the maximum size that a ReadyNow profile log is allowed to reach. Profiles get truncated at this size, regardless of whether the application has actually been completely warmed up. This parameter has a server-side counterpart It is recommended to either not set this size explicitly, or set it generously if required, for example:
|
0 |
||
-XX:ProfileLogTimeLimitSeconds=<value in seconds> [1]"For more information |
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 |
||
-XX:ProfileLogDumpInputToFile=<name> |
Dumps input profile to the specified path. For debugging purposes only. |
null |
||
-XX:ProfileLogDumpOutputToFile=<name> |
Dumps output profile to the specified path. For debugging purposes only. |
null |
||
-XX:RNOConnectionTimeoutMillis |
Timeout on establishing remote connection and timeout on interval between downloading two chunks. Specified in milliseconds. |
5000 |
||
-XX:RNOProfileFallbackInput |
Experimental feature. Local filesystem path which gets used in case no profile data is downloaded. E.g., in case of a missing connection or the requested profile name doesn’t exist on the server. |
null |
||
-XX:ProfileLogOutVerbose |
Enables logging of verbose, optional tracing information in |
true |
The profile name is the central organizing attribute that ReadyNow Orchestrator uses to group together profile logs. ReadyNow Orchestrator regards all candidates it receives that contain the same profile name as being for the same application, with no further knowledge of what code was actually runs. This poses the danger of accidentally using the same profile name for two different applications. For example, if a user copies and pastes the command-line arguments, including the profile name, from a production application and uses it to run HelloWorld, the HelloWorld profile could, in some cases, replace your valid production application profile.
To avoid this danger, you can use substitution macros in your profile name to limit the likelihood of profile name clashes between different applications. 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 |
%prop=<PROPERTY>% |
Substition macro defining the profile log name. This gets replaced with the value of the corresponding Java system property. Provide these properties to the JVM on startup with For example: |