Path: blob/master/doc/compiler/jitserver/Usage.md
6000 views
Getting started with JITServer
This document explains how to use JITServer technology with any Java application and describes some basic options, such as network configuration, logging and encryption.
Running applications with JITServer
JITServer adds two additional personas to the JVM: client mode and server mode. In client mode the JVM will execute the given Java application as usual, but it will delegate JIT compilations to a server process.
In server mode, the JVM will halt after startup and begin listening for compilation requests from clients. To start the server, run the jitserver
launcher present under bin
directory (alongside java
launcher). No Java application is given to the jitserver
launcher on the command line. Any option accepted by JVM can also be passed to the jitserver
launcher. One server is capable of serving multiple clients.
Begin by launching the server:
Note: we passed an option
-XX:+JITServerLogConnections
to the server to enable logging of client connection events. Refer to this section for more information.
To start the JVM in client mode, provide the -XX:+UseJITServer command line option to the java launcher. In the following example we assume the client and the server are run on the same machine. Since the server needs to continue running, we need to start the client in a new terminal.
Open a new terminal window and launch a simple program as client:
Note:
java -version
is itself a small Java application! If you have some application you'd like to test, you can substitute it in for-version
. Run it as usual, but with the flag-XX:+UseJITServer
before the application name.
If you go back to the server, you will see that it printed out that a client connected to it, which is how we can confirm that JITServer is working.
If at any time during the client's lifetime the server goes down or becomes unaccessible, the client will automatically switch to local compilations and will continue running like a regular JVM until the server becomes available again.
Network Configuration
In the above example we assumed that both client and server are run on the same machine. However, in real life scenarios they will likely be running on different machines connected by a network. For example, they could be containers running on two different nodes in a cloud cluster. JITServer provides command line options to configure network parameters, such as server address, ports, and encryption.
Hostname/IP Address
On the client, you can specify server's hostname or IP address with -XX:JITServerAddress
option.
By default, the server address is set to localhost
, i.e. server and client are on the same machine.
Port
By default, communication occurs on port 38400
. You can change this by specifying the -XX:JITServerPort
suboption as follows:
Timeout
If your network connection is flaky, you may want to adjust the timeout. Timeout is given in milliseconds using -XX:JITServerTimeout
suboption. Client and server timeouts do not need to match. By default there is timeout of 30000 ms at the server and 10000 ms at the client. Typically the timeout at the server can be larger; it can afford to wait because there is nothing else to do anyway. Waiting too much at the client can be detrimental because the client has the option of compiling locally and make progress.
Encryption (TLS)
By default, network communication is not encrypted. If messages sent between the client and the server need to traverse some untrusted network, you may want to set up encryption. Encryption reduces performance, i.e. compilations take longer and consume more CPU, so consider whether it is required for your use case.
To generate some keys for testing, try:
Make sure you specify localhost for the common name, but other fields don't matter (they can be left blank). Keys generated in this manner should NOT be used in production!
On the server, there are two options sslKey
and sslCert
, which are used to specify the filenames of PEM-encoded keypair.
The client currently accepts a single option sslRootCerts
, which is the filename of a PEM-encoded certificate chain.
JITServer-specific options
JITServer heuristics
If a client is given the option -Xjit:enableJITServerHeuristics
, it will attempt to guess which compilations are "cheap" (in terms of resources required) and perform them locally, instead of making a compilation request to a server. The reasoning here is that for cheap compilations, overhead of network communication is larger than resources required to compile locally. With heuristics enabled, client will try to maximize benefits of using JITServer while minimizing overheads.
JITServer AOT cache (experimental)
The server-side option -XX:+JITServerUseAOTCache
enables storing AOT methods on the server. This allows the server to send AOT method bodies to clients that do not have pre-populated Shared Class Caches, improving startup time.
This is currently an experimental feature and it is not fully supported.
Logging
As mentioned previously, running the client without any server to connect to still appears to work. This is because the client performs required JIT compilations locally if it cannot connect to a server. To ensure that everything is really working as intended, it is a good idea to enable some logging. It's often most convenient on the server side, because log messages will not interfere with application output, but logging can be added to either the server or the client.
Connection logging
Option -XX:+JITServerLogConnections
can be enabled on both the server and the client. It is the simplest form of JITServer logging. When enabled, connection and disconnection events will be logged to standard error or verbose log (if vlog is specified).
Sample server output:
Sample client output:
This option can also be enabled with a verbose option -Xjit:verbose="{JITServerConns}"
.
JITServer heartbeat
Server has a statistics thread running in the background, which can periodically print general information about the state of the server. Use -Xjit:statisticsFrequency=<period-in-ms>
option to enable heartbeat logging. The output looks like this:
This option is useful for tracking the state of JITServer over time, particularly for tracking things like available memory and CPU usage.
Verbose logs
With verbose logging, if a client connects successfully then server output should look something like this:
JITServer prints out information about new client connections, new networking streams, successful compilations, etc. The same option can be used on the client to log similar information.
JITServer version
Note that JITServer prints out version information that is different from java -version
output. To use JITServer, client and server must have matching versions. To check client's version pass it verbose=\{JITServer\}
option as well.