brief introduction

Want to know the GC tuning secrets in jdk12, 13 and 14? Want to know what new changes have been made to the JVM in these three versions?

Let's take a look at the GC tuning script in this issue. Because the GC in jdk12, 13 and 14 doesn't change much, let's make a summary here. The corresponding pdf download is attached at the end of the article. I hope you can like it.

Those easy-to-use VM parameters

Let's talk about some easy-to-use VM parameters that were not mentioned in previous versions.

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=path

When we write Java programs, we often encounter program reports Java Lang. outofmemoryerror exception. How do we solve the excellent problem at this time?

As soon as senior programmers see this error, they know that the heap space is not enough. Increase the heap space.

But smart programmers may ask, why is this outofmemoryerror exception? Is there a problem in our program?

With this question, smart programmers may use the jmap command to dump heap, and even some programmers can skillfully use jcmd PID GC heap_ Info command to view heap info.

These are all very good, but if you use the above two JVM options, the program will automatically dump the heap whenever outofmemoryerror appears. The default file name is Java_ pid. Hprof, you can also specify the file path yourself.

-XX:+PrintClassHistogram

Sometimes, you can use this option if you need to count class information.

Corresponding statistical events will be triggered when control + C is received in Windows environment or control + break signal is received in Linux environment.

I have a little friend to ask. What are the control + C and control + break signals? How to pass signals to Java programs?

Here's an extension for you. You can use the kill command to send a signal.

Kill actually has two uses.

The first type is kill PID, which is directly followed by a PID.

Second, kill - term PID, term is the signal we want to pass to kill.

In fact, kill PID is short for kill - 15 PID.

Let's use kill - L to see the signal types supported by kill:

kill -l 
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXcpu     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

We commonly use 9 = sigkill, that is, to send a forced kill signal to the JVM.

-XX:+PrintConcurrentLocks

Similarly, printconcurrentlocks also outputs Java. Net when receiving control + break or control + C signals util. Lock information of concurrent.

-XX:+PrintFlagsRanges

Let's take another look at a more useful parameter, printflagranges. Sometimes we want to use some VM parameters, but we don't know the value range of these parameters, so we can use printflagranges. Let's try:

Isn't it very useful?

Change of G1

JVM is developing and G1 parameters are also developing. In these versions, several G1 parameter names have changed:

-20: Replace defaultmaxnewgenpercent with - XX: g1maxnewsizepercent = percent

-20: Replace g1oldcsetregionlivethresholdpercent with - XX: g1mixedgclivethresholdpercent = percent

-20: Replace defaultminnewgenpercent with - XX: g1newsizepercent = percent

Configure flightrecorder

Java flight recorder (jfr) is a diagnostic and performance analysis tool for the JVM. It can collect data about the JVM and the Java applications running on it. Jfr is integrated into the JVM, so jfr has little impact on the performance of the JVM. We can use it safely.

Generally speaking, when using the default configuration, the performance impact is less than 1%.

Jfr is a low overhead analysis engine based on events. It has a high-performance back-end and can write events in binary format.

Jfr is a JVM tuning tool that provides data for subsequent JMC analysis by constantly collecting various events in the JVM and Java applications.

Event is composed of three parts: timestamp, event name and data. At the same time, jfr will also handle three types of events: events lasting for a period of time, events triggered immediately and sampled events.

In order to ensure the latest impact on performance, please select the event type you need when using jfr.

After jfr collects events from the JVM, it writes them into a small thread local cache, then flushes them into a global memory cache, and finally writes the data in the cache to disk.

Or you can configure jfr not to write to disk, but only part of the events information will be saved in the cache.

The flightrecorder has two parts of configuration. The first part is to configure the size, storage and other information of the flightrecorder itself. The second part is the opening options of flightrecorder.

Let's take a look at the configuration parameters related to flightrecorder:

-XX:FlightRecorderOptions:parameter=value

The following is the configuration of startflightrecording:

-XX:StartFlightRecording=parameter=value

Ram parameters

By default, the maxheapsize of the JVM is automatically configured according to the size of ram. For example, I have a machine with 8g memory and execute the following command:

java -XX:+PrintFlagsFinal -version | grep -Ei "maxheapsize|maxram"

You can see maxheapsize = maxram / maxrampercentrage.

VM also provides the following parameters for setting ram related parameters:

-XX:MaxRAM=size
-XX:InitialRAMPercentage
-XX:MaxRAMPercentage
-XX:MinRAMPercentage

It mainly sets the maximum RAM value and the proportion of heap in RAM.

Ram parameters are mainly configured for Java to run in the container.

ZGC in jdk13

In jdk13, we can start the ZGC experience. ZGC is a scalable, low latency GC. ZGC is concurrent and does not need to stop running threads.

ZGC was introduced in JDK 11.

We start ZGC in the following ways:

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

RTM support

Restricted transactional memory (RTM) is a restricted transactional memory. It is an instruction set system introduced by Intel in x86 microarchitecture. It belongs to TSX (transactional synchronization extensions) instruction set extension.

RTM is mainly used to improve execution efficiency in multi-threaded environment.

RTM introduces xbegin, xabort, xend and xtest. The effect of transaction can be achieved by including instructions between xbegin and xend.

RTM can be regarded as a coarse-grained lock. The code contained between xbegin and xend is the program to be executed. RTM can automatically detect data conflicts in operations by hardware to ensure the correctness of transactional operations, so as to explore the parallelism between operations.

At the same time, RTM can also reduce the false sharing of CPU cache line.

RTM supports four main parameters:

-XX:+UseRTMLocking

-XX:+UseRTMDeopt

-XX:RTMAbortRatio=abort_ratio

-XX:RTMRetryCount=count

Usertmdeopt and rtmabortratio are used together.

We mentioned earlier that RTM will optimize coarse-grained locks, but if multiple threads access the same resources concurrently, this optimization is actually unsuccessful. It will be abort and then fall back to the normal lock state.

If abort exceeds a certain percentage, the RTM code will be de optimized.