Introduction to the

The author had the honor to read teacher Zhou Zhiming’s “In-depth Understanding of Java Virtual Machine” god book, was deeply impressed by the teacher’s rich experience in tuning, I also want to try; The book is Eclipse tuning, the author is using Idea, in the spirit of emulating the mood, and share with you my Idea tuning process

Prepare to tune the environment

This command is used to monitor VM running

JPS -l # returns the running PID of the Java virtual machine, Jstat-gccause PID # returns the cause of gc and statistics. Jstat-class PID # returns the cause of gc and statistics. Jvusualvm # GUI tool for monitoring JVM health, including heap, non-heap, thread, CPU usageCopy the code

To visualize GC, it is recommended that you install the Visual GC tool. Installation address: https://visualvm.github.io/pluginscenters.html, if can’t access, please see my last post how to solve. The renderings after installation

Monitor IDEA JVM parameter changes and print GC information

1, first start JvusalVM, then start IDEA, wait until the IDEA icon appears click in

Enter the VisualGC page and start recording GC information

2. Parameters required to record GC print information

-xloggc :gcc.log # Print gc information to gcc.log on the desktopCopy the code

Write the parameters in the CONFIGURATION file of DRIVE C, not in the configuration file of the IDEA installation location.

After the preceding two steps are complete, start IDEA.

Idea Indicates the time required for starting each part

1. After idea startup is complete, check idea startup PID using JPS:

2. View the class loading and unloading information

It can be seen that the results obtained by Using VisualGC and command line are consistent, and 38.953s is spent for loading and unloading the class

3. Check the runtime compilation status

The fuck_the_regulations method type caught my eye

Compilation time: 41.676s

4. View GC information

It can be seen that 80 minorgcs occurred, which took 600ms, and no FullGC occurred. Is the excessive number of GC caused by the insufficient Cenozoic generation? So look at the GC information (here is a representative sample of a dozen GC information)

You can see that the heap has grown from 123M to 382M, which must have taken some time

Try to optimize the Angle

1, real-time compilation time is too long (41.676s)

For the first point, idea has been optimized. Some of you may have noticed that we started IDEA for less than 40 seconds. Yes, some classes are still compiling after we started IDEA. Idea can be compiled while working; This is because of the CMS garbage collector. Since the CPU usage is not high when IDEA is started, we can consider consuming processor resources to achieve compilation and work at the same time. CMS is more suitable for this scenario. Using SerialOld here causes a noticeable compilation pause; You can, of course, disable the just-in-time compiler by using -xint. Then I found that idea started more slowly, no compilation time was obtained, but the loading and unloading of the class took 57.12s!

For the problem that the real-time compilation time is too long, we keep the original idea configuration

2. Class loading and unloading time is too long (38.953s)

For the second point, since class loading includes: Loading (loading the Class into memory), validating (verifying that the Class loaded into memory matches the virtual machine format), preparing (opening up memory, assigning default initializers 0, NULL, false, etc.), parsing (converting symbolic references to direct references), initializing (initializing static variables). We can turn off the validation phase of the class with the argument -xVerify: None, because we can assume that the class idea is loading is safe.

After the configuration, the loading and unloading time of the class is 31.72s, 7s less than the previous 38.95s. Feel idea start faster! Of course, I also found that idea frequently opened its real-time compilation time is shorter!

Compared with 41.45s before, it only took 30.58s now; The name comes from the fact that the HotSpot just-in-time compiler identifies frequently running code as HotSpot code, which is then compiled into native code by the just-in-time compiler to make it run faster. No wonder my idea is getting faster and faster!

3. MinorGC occurs too many times, which is accompanied by heap expansion

Based on the previous analysis, we can expand the memory size of the new generation heap as follows:

-xms512m -xmx512m # Since the heap was finally expanded to 364M, we conservatively allocated 512m-xmn256m to itCopy the code

conclusion

After the above configuration, my idea was so fast that MY scalp was numb. Let me show you the final test results

The loading time of the class is greatly reduced (the loading of the class does not directly affect the startup speed of IDEA, which is shown as 28s, but the startup of my IDEA is now started within 10s instead of more than 40 s before). MinorGC frequency is reduced, and there is no heap expansion time. Real-time compilation is also reduced compared to before.

Angles that can continue to be optimized:

1. Upgrade the JDK version

2. Using the G1 collector or other low-latency garbage collectors, I have found that G1 performs better than CMS

3. Further optimization of compile time and class loading time

4. As the number of GC is very small, the space for optimization is relatively small

Finally, post my IDEA configuration (some parameters may not be suitable for your machine, here is mainly to introduce the tuning method)

-Xms768M -Xmx768M -Xmn384M -XX:ReservedCodeCacheSize=240m -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -Xverify:none -ea -XX:CICompilerCount=2 -Dsun.io.useCanonPrefixCache=false -Djava.net.preferIPv4Stack=true -Djdk.http.auth.tunneling.disabledSchemes="" -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow - Djdk. Attach. AllowAttachSelf - javaagent: C: \ Users \ Public \. Jetbrains \ jetbrains - agent - v3.2.0 de72.619Copy the code