Shulou(Shulou.com)06/03 Report--

How to shorten the time for eclipse to start JVM optimization, I believe many inexperienced people do not know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Add: first of all, let's make it clear that this case is also mentioned in this book. This book is the one I used to study JVM. The optimization idea about Heap in it comes from this. It is recommended that you want to learn the principle of JVM, you can find this book to have a look. I wrote this article because I was tuning a social networking server recently, and I suddenly felt that I had more eclipse running on my machine, so I optimized eclipse by the way. As for WebSphere server-based performance tuning, this involves more tools and methods, which will be seen in future articles.

Recently, since eclipse installed many plug-ins, the startup has become very slow, each startup takes nearly half a minute. This is not normal. I decided to optimize it today.

The eclipse I use is Eclipse Java EE IDE for Web Developers 3.8. Running on MAC OSX, SSD+8G RAM, it doesn't make sense that such a high-performance machine can't turn on eclipse. Oh, and the JVM I use is Oracle's HotSpot, which comes from JDK1.6 64bit.

First of all, before optimizing, let's take a look at the performance indicators of JVM when eclipse starts. Since I can't accurately determine the startup completion time of eclipse, I can only say about the event.

First start the JVM performance monitoring tool that comes with JDK. In the java\ bin directory, there is a jvisualvm, which is the visualvm bound in JDK. Double-click to start visualvm. Then start eclipse. After eclipse is started, use visualvm to check the Visual GC of eclipse, as shown in the figure:

The figure above shows that during the startup of eclipse, JIT compiled the bytecode to machine code in 22 seconds. Class load took 10 seconds, Minor GC 72 times, 0.64 seconds, Full GC 12 times, only 61 milliseconds.

Let's go to the MBean option and find that the new generation uses the ParNew garbage collector, while the old generation uses the CMS garbage collector.

Generally speaking, due to the good performance of MAC, garbage collection does not consume too much time, and CMS+ParNew itself is parallel garbage collection, which will not cause too much pause in user programs. Time is mainly spent on real-time compilation of JIT and Class loading.

The first thing to optimize is class planting. Because eclipse is a mature tool that has been verified by so many people, I fully trust eclipse code and allow eclipse code to skip bytecode verification when loading. The way to turn off bytecode verification is to add the parameter-Xverify:none. Xverify:none. For eclipse, find eclipse.ini and add-Xverify:none. Let's restart eclipse again to see if the class load time is reduced. Start again and find that the class load event has shrunk to 7 seconds, 3 seconds less than before.

Then the time of JIT is optimized. When writing programs with eclipse, it is mainly text editing, compiling and running. Although JIT can bring us high performance, JIT consumes a lot of time when compiling machine code. Eclipse compiles and runs the project very slowly, and the runtime starts a new java process, which has nothing to do with eclipse itself, so I can accept the inefficiency of abandoning the JIT compiler and just using the JVM interpreter to execute bytecode. This removes the JIT compilation time. To do this, add the parameter-Xint of vm to eclipse.ini, which means only the interpreter is used. Let's look at the results:

The JVM compiler time becomes 0, minus 20 seconds. However, due to the lack of just-in-time compilation optimization at runtime, the running time of the code becomes longer, and the overall startup time of eclipse is much slower, more than 30 seconds. This shows what a useful technology JIT is. So the attempt to ban JIT failed. Let's remove the previous parameter-Xint.

Oh, by the way, I also installed a lot of plug-ins, especially android development plug-ins. It also takes a lot of time to activate the plug-in at startup. The method to block plug-in activation: Windows-> Preferences, type "startup", click "Startup and Shutdown", and uncheck the unwanted plug-ins. In addition, you need to turn off unnecessary validation by: Windows-> Preferences-> Validation. Choose only what you need.

After doing the above work, I found that eclipse started a little faster. It took about 15 seconds to pinch the stopwatch.

*, optimize the GC and stack again. Although GC has performed very well, no more than 1 second, but the frequency of GC is so high, it shows that the memory allocation of JVM is unreasonable. To do this, we need to repartition the JVM memory. In order to allocate JVM memory properly, we need to understand what happened to GC during eclipse startup. The method to open gc log is as follows:

To add to the vm parameter of eclipse.ini

-XX:+PrintGCDetails

-Xloggc:/users/joey/Documents/gc.log

Start eclipse, generate gc.log, open log, and analyze.

Minor GC found that the size of the Cenozoic is about 20m. The size of the heap is about 40m. Then in the next GC, the new generation never expanded its capacity. This shows that the Cenozoic generation is of the right size.

0.720: [GC 0.720: [ParNew: 17024K-> 2112K (19136K), 0.0099529 secs] 17024K-> 2324K (38848K), 0.0100285 secs] [Times: user=0.03 sys=0.00, real=0.01 secs]

* * when Full GC occurs, it is found that the capacity has been expanded to about 93m in the old age and to about 128m in the immortal generation.

67.213: [Full GC (System) 67.213: [CMS: 57969K-> 57877K (93124K), 0.3563491 secs] 62179K-> 57877K (112260K), [CMS Perm: 80490K-> 80392K (128708K)], 0.3565176 secs] [Times: user=0.36 sys=0.00, real=0.36 secs]

Until the first GC, the occupation of the old age did not exceed 125m, and the occupation of the immortal belt did not exceed 125m. But they all take up more than 100m of space. Therefore, it is reasonable to specify an initial heap size. Finally, through the analysis, I added the following parameters to eclipse.ini:

-server-Xverify:none-XX:PermSize=128m-XX:MaxPermSize=256m-Xms256m-Xmx512m-Xmn40m-Xss2m

-server is to let JVM run in server mode, which aggravates the optimization effect of JIT. Because eclipse is often turned on and off, in server mode, JIT will turn bytecode into machine code more profoundly as time goes by. Speed up the running speed.

-Xverify:none, skip bytecode verification.

The PermSize immortal belt is set to 128m, the initial size of the heap is set to 256m, and the Cenozoic station is 40m. Each thread stack size is set to 2m.

In this setting, Full GC has completely disappeared, but there are still 20 or so Minor GC left, which takes about 0.3 seconds, which is acceptable. If the space of the new generation is increased in order to completely eliminate GC, it is also a waste of memory. Restart eclipse, the startup time has fallen within 15 seconds. As shown in the figure:

After reading the above, have you learned how to shorten the time it takes for eclipse to start JVM optimization? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.