Enabling the JBolt Feature

Introduction

In mainstream just-in-time (JIT) compilation, method code is added to the code cache based on compilation timing. When there are a large number of hot, scattered methods, iCache/iTLB miss causes high CPU penalty, resulting in front-end system bottlenecks. The JBolt feature uses sampling to obtain the hotspots and call chains of JIT methods at runtime, and then uses algorithms to reorder hot method code, which improves spatial locality, reduces the iCache/iTLB miss rate, and boosts program performance.

Application Scenario

The iCache/iTLB miss rate is high due to high JIT code cache usage, and there are many hot, scattered methods in the program. (You can use a performance analysis tool to trace the CPU cache hit rate, such as the Linux perf command.)

Restrictions

The JBolt feature is available in BiSheng JDK 11 (since 11.0.27) and BiSheng JDK 17 (since 17.0.14).
Applications need to support JDK Flight Recorder (JFR). Generally, applications support JFR by default, unless the -XX:-FlightRecorder parameter is used to disable this function.
The C2 compiler must be enabled. The JBolt feature cannot be used when the compiler is disabled, such as in the -Xint and AppCDS dump scenarios.
Applications need to support segmented code cache. JBolt depends on the segmented code cache feature (enabled by default) in Java versions later than 9. If an application contains -XX:-TierdCompilation, -XX:-SegmentedCodeCache, and -XX:ReservedCodeCacheSize < 240M, this feature will be disabled. As a result, JBolt cannot be used.

(Recommended) Method 1: One-Step Mode

In this mode, sampling and reordering are automatically completed within the same program running phase. Repeated sampling and reordering are also supported.

Enable and start JBolt to automatically perform sampling and reordering. It is strongly recommended that the -Xlog:jbolt=info parameter be added. This parameter will output information to the console in each important phase of JBolt. After sampling, reordering is automatically performed. If the -Xlog parameter is added, "JBolt reordering succeeds" is displayed after the reordering is done, indicating that the JBolt feature takes effect. This parameter is also applicable to the two-step mode. In the following command, spring-petclinic.jar is an example of the service program package. Replace it with your target program.
1
$JAVA_HOME/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJBolt -Xlog:jbolt=info -jar spring-petclinic.jar
In one-step mode, the following parameters can be used together:
- -XX:JBoltSampleInterval: sampling duration, in seconds. Unless otherwise specified, the default value is 600.
- -XX:JBoltCodeHeapSize: JBolt heap size. The default value is 8M. This value may be insufficient in scenarios where there are many compilation methods (the initial code cache usage is high). You need to configure this parameter based on the scenario and align the value with the page size. The reference value is 1/4 to 1/2 of the used non-profiled size. (Use the -XX:+PrintCodeCache parameter to query. For example, if non-profiled used=16M, set JBoltCodeHeapSize to a value between 4M and 8M.)
- -XX:JBoltRescheduling: automatic sampling at a fixed time every day (supported only in JDK 11). The format of the value must be hh:mm. Use commas (,) to separate multiple time points, for example, JBoltRescheduling=07:30,16:30. A maximum of 10 non-overlapping time points can be set. (Only one JBolt workflow can be executed at a time point. If a previous workflow does not complete due to closely set time points, manual sampling, or other reasons, the next workflow may fail to be automatically triggered and will be skipped on that day.)
Use jcmd to manually set the sampling time and start JBolt hotspot reordering online.
The following commands are supported. Usage: jcmd <pid> JBolt.xxx

<pid> indicates the ID of the Java process enabled in 1. Replace it with the actual PID.
- JBolt.start: starts automatic sampling in an interval and performs reordering after the sampling ends. The duration parameter can be used as required. It has the same meaning as -XX:JBoltSampleInterval and defaults to the value of JBoltSampleInterval. Example:
  1
  $JAVA_HOME/bin/jcmd <pid> JBolt.start [duration=<sample interval>]
  If sampling or reordering is being performed, this command will fail. You can wait until the current process is complete or run the stop or abort command to end the current process in advance.
- JBolt.stop: immediately stops current sampling and performs reordering. Example:
  1
  $JAVA_HOME/bin/jcmd <pid> JBolt.stop
- JBolt.abort: similar to JBolt.stop but does not perform reordering. Example:
  1
  $JAVA_HOME/bin/jcmd <pid> JBolt.abort
- JBolt.dump: exports the sequence table in the current application. A valid file path must be specified in the filename parameter. Example:
  1
  $JAVA_HOME/bin/jcmd <pid> JBolt.dump filename=<eg: order.log>

Method 2: Two-Step Mode

In this mode, sampling and reordering are performed in two phases.

Enable the dump mode and perform sampling. The sampling persists until the program exits normally or is manually stopped by running Ctrl+C. In this case, the sequence table is exported to a specified file (not exported upon an abnormal exit).
1
$JAVA_HOME/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJBolt -XX:+JBoltDumpMode -XX:JBoltOrderFile=<eg: order.log> -Xlog:jbolt=info -jar spring-petclinic.jar
Use the generated sequence table file to start the program again for layout reordering. The reordering is performed after the application program is started for a period of time. For details about how to verify whether this step takes effect, refer to step 1 in the one-step mode. After the reordering takes effect, the program performance is expected to be improved.
1
$JAVA_HOME/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJBolt -XX:+JBoltLoadMode -XX:JBoltOrderFile=<eg: order.log> -Xlog:jbolt=info -jar spring-petclinic.jar
In two-step mode, the jcmd command cannot be used to set the sampling time.

Parent topic: BiSheng JDK Acceleration Library User Guide