Visit Azul.com Support

Using ReadyNow Orchestrator

Table of Contents
Need help?
Schedule a consultation with an Azul performance expert.
Contact Us

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.

Advantages of ReadyNow Orchestrator

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.

Creating and Writing To a New Profile Name

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.

ReadyNow Orchestrator JVM Options

The following options are available in Azul Prime when using ReadyNow Orchestrator with Optimizer Hub:

Command Line Option Description Default

-XX:OptHubHost=<dns>

DNS name of the Optimizer Hub service where Optimizer Hub is listening, as specified . The default is localhost:50051. See Connecting a JVM to Optimizer Hub for instructions to determine the correct host and port.

null

-XX:ProfileName=<name>

Name of the profile that the JVM both reads from and writes to. Use of this flag is equivalent to using -XX:ProfileLogIn=<name> -XX:ProfileLogOut=<name>, and is the preferred way to specify profile names when different input and output names are not needed. If prefixed with opthub://, <name> is used as the profile name in ReadyNow Orchestrator. If not prefixed with opthub://, <name> is interpreted as a file path on the JVM.

null

-XX:[+/-]EnableRNO

Enables ReadyNow read and write to ReadyNow Orchestrator. Requires OptHubHost and uses ProfileName as the name for the profile log.

false

-XX:ProfileLogOut=<name>

The ProfileLogOut enables Zing to record compilations from the current run. <name> is the name of the profile that the JVM reads as input to ReadyNow. If prefixed with opthub://, <name> is used as the profile name in ReadyNow Orchestrator. If not prefixed with opthub://, <name> is interpreted as a file path on the JVM.

Note
 For local ReadyNow you often have to specify different names for ProfileLogIn and ProfileLogOut. But for ReadyNow Orchestrator you must only use ProfileName.

null

-XX:ProfileLogIn=<name>

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. <name> is the name of the profile that the JVM reads as input to ReadyNow. If prefixed with opthub://, <name> is used as the profile name in ReadyNow Orchestrator. If not prefixed with opthub://, <name> is interpreted as a file path on the JVM.

Note
 For local ReadyNow you often have to specify different names for ProfileLogIn and ProfileLogOut. But for ReadyNow Orchestrator you must only use ProfileName.

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 = never gets promoted

1M

-XX:ProfileLogOutNominationMinSizePerGeneration

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 ,. For example:

 
0:1000000,1:10000000,2:25000000,3:50000000

For more information, check Understanding ReadyNow Orchestrator Generations.

null

-XX:ProfileLogOutNominationMinTimeSec

When used with ReadyNow Orchestrator, the minimum time, in seconds, a profile must record before ReadyNow Orchestrator can nominate it as a candidate.

0 = any duration eligible

-1 = never gets promoted

120

-XX:ProfileLogOutNominationMinTimeSecPerGeneration

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 ,. For example:

 
0:100,2:150

For more information, check Understanding ReadyNow Orchestrator Generations.

null

-XX:ProfileLogOutMaxNominatedGenerationCount

When used with ReadyNow Orchestrator, specifies the maximum generation of a profile that a VM nominates.

This parameter has a server-side counterpart readyNowOrchestrator.producers.maxPromotableGeneration. The profile has to satisfy both settings to be promoted.

0 = unlimited

For more information, check Understanding ReadyNow Orchestrator Generations.

0

-XX:ProfileLogMaxSize=<value in bytes>

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 readyNowOrchestrator.producers.maxProfileSize. The profile will be allowed to reach whatever is the smallest of both settings.

It is recommended to either not set this size explicitly, or set it generously if required, for example:

-XX:ProfileLogMaxSize=1G

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>

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 -XX:ProfileLogOut

true

Substitution Macros

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 -Dprop=value.

For example:

 
-Dmyprofilename=test-profileout \
  -XX:ProfileLogOut=opthub://%prop=myprofilename%