Visit Azul.com Support

Connecting a JVM to a Cloud Native Compiler

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

You connect an Azul Zulu Prime Build of OpenJDK (Azul Zulu Prime JVM) to a Cloud Native Compiler service by specifying the IP address of the service along with other command-line options. If the Cloud Native Compiler cannot respond to the compilation requests in time, the Azul Zulu Prime JVM switches to local JIT compilation until the service recovers.

Note
 You can only connect to Cloud Native Compiler from any Azul Zulu Prime JDK versions 21.09.1.0 and later.

To connect, you will need to use one or, in a some cases two, JVM flags:

  • CNCHost

  • CNCEngineUploadAddress - only when using non-standard ports

Determining the Cloud Native Compiler Endpoint

Use the IP address of the Cloud Native Compiler gateway service as the connection endpoint for your JVMs.

JVMs running in the same Kubernetes cluster

If the containers running your JVMs are deployed to the same Kubernetes cluster as the Cloud Native Compiler service, the service endpoint is gateway.compiler.svc.cluster.local. Connect the JVMs using:

 
$ java -XX:CNCHost=gateway.compiler.svc.cluster.local -jar my-app.jar

You do not need to specify a value for CNCEngineUploadAddress.

Using an External Load Balancer

It is strongly recommeneded that your front your CNC service with am external load balancer. If you correctly defined the load-balancer in values-override.yaml as described in Installing Cloud Native Compiler, you can discover the external IP of the service using the following command:

 
$ $ kubectl describe service gateway -n compiler | grep 'LoadBalancer Ingress:'
$ LoadBalancer Ingress:     internal-add1ff3e1591e4f93a49af3523b68e3b-1321158844.us-west-2.elb.amazonaws.com

You then connect using the following command:

 
$ java -XX:CNCHost=internal-add1ff3e1591e4f93a49af3523b68e3b-1321158844.us-west-2.elb.amazonaws.com -jar my-app.jar

You do not need to specify a value for CNCEngineUploadAddress.

Connecting Without an External Load Balancer

If the containers are deployed outside the Cloud Native Compiler cluster, but you did not set up a load balancer, you can find the endpoint using the following steps:

  1. Run the following command:

     
    $ kubectl -n compiler get services

  2. Look for the gateway service and note the ports corresponding to ports 50051 and 8080 inside the container. This is the port to use for connecting VMs to this Cloud Native Compiler cluster.

     
    $ service/gateway NodePort    10.233.15.55    <none>  8080:31951/TCP,50051:30926/TCP  52d

    In this example the ports are 30926 and 31951.

  3. Run the kubectl get nodes command and note the IP address or name of any node.

  4. Concatenate node IP with service ports to get something like 10.22.20.131:30926 and 10.22.20.131:31951. Do not prefix it with http://.

  5. Set -XX:CNCHost=host:port flag to the port mapped to 50051 and the -XX:CNCEngineUploadAddress=host:port flag to the port mapped to 8080.

     
    $ java -XX:CNCHost=10.22.20.131:30926 -XX:CNCEngineUploadAddress=10.22.20.131:31951 -jar my-app.jar

Logging and SSL

To view compiler info and ensure that the JVM is correctly connecting to the CNC service, use the -Xlog:concomp flag.

By default the Azul Zulu Prime JDK connects to the CNC service using SSL. If you did not enable SSL during CNC deployment, you must use the -XX:+CNCInsecure flag to instruct the Azul Zulu Prime JDK to connect without SSL.

If you attempt to connect to a CNC service that is running without SSL and do not specify the -XX:+CNCInsecure flag, you get the following error (visible with the -Xlog:concomp flag):

 
$ E1011 13:16:23.198074100      29 ssl_transport_security.cc:1446] Handshake failed with fatal error SSL_ERROR_SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number.

Cloud Native Compiler JVM Options

Flag Description

-XX:CNCHost=host:port

Address where CNC service is listening. The default is localhost:50051.

-XX:CNCEngineUploadAddress=host:port

Address to upload compilation engines. Only needed when using autoupload and nonstandard ports of the service.

-XX:CNCMaxConcurrentCompiles=M

Maximum number of compilation requests a JVM sends to remote compiler before blocking and waiting for results. Default value is -1, which defers to the settings in the gateway pod config. Set to a positive number to override the service setting and use this number as the value.

-XX:+CNCAbortOnBadChannel

With this flag VM will crash if it loses connection to remote compiler.

-XX:+CNCInsecure

Instructs the Azul Zulu Prime JVM to communicate directly with the CNC service without using SSL. Use this option if you installed the CNC service without SSL.

-XX:CNCSSLRootsPath=<path to cert.pem>

Instructs the Azul Zulu Prime JVM to use and trust a specified SSL certificate on the filesystem

-Xlog:concomp

Display compiler output when running a program.

Fallback to Local JIT Compilation

When you connect an Azul Zulu Prime JVM to a Cloud Native Compiler (CNC), the JVM attempts to fetch all JIT compilations from the service. If the Cloud Native Compiler cannot meet the JVM’s requests in time, the JVM automatically falls back to performing optimizations on the client. Factors that can cause a Cloud Native Compiler service to not meet optimization demand include:

  • The service does not have the corresponding Compiler Engine installed. To force an Azul Zulu Prime JVM to fail when requesting optimizations from a Cloud Native Compiler that doesn’t have the corresponding Compiler Engine installed, use the -XX:+CNCAbortOnBadChannel flag.

  • The service is down or cannot be reached.

  • The service does not have enough capacity to meet the optimization requests. If you have autoscaling enabled, this is often a temporary problem as new resources come online.

When an Azul Zulu Prime JVM switches to local JIT compilation, it keeps checking whether the Cloud Native Compiler service is ready to perform optimizations. Once the Cloud Native Compilation service is back online and healthy, the Azul Platform Prime JVM switches back to requesting optimizations from the service.

The following output in the JVM concomp log show when fallback to local JIT compilation is enabled and disabled:

 
$ [110,991s][info   ][concomp] [LocalFallback] local compilation queue disabled
$ [111,018s][info   ][concomp] [LocalFallback] local compilation queue enabled

Using Cloud Native Compiler with ReadyNow

You can use Cloud Native Compiler with ReadyNow to shorten the pre-main JIT compilation time of ReadyNow. You pass a ReadyNow profile into a JVM that is configured to use Cloud Native Compiler as normally using the -XX:ProfileLogIn=<file> flag.

Note
 Using -XX:ProfileLogOut=<file> to generate a profile from a JVM that is using Cloud Native Compiler is not fully supported at this time. Using this profile could have unexpected results. You should generate your profile with an Azul Zulu Prime JVM that is doing local JIT compilation.