This article is my 12 years of studying "in-depth understanding of the Java Virtual Machine: JVM advanced features and best practices", the JVM to do a simple tuning practical note, are somewhat outdated version, but the tuning process can still share ideas and give everyone for reference.

Environment Basic Configuration

Hardware: the Dell E5410, the CPU M Intel i3 370, 2GB RAM

System: 32-bit Windows XP

Virtual machine: the Java HotSpot (TM) Client VM (Build 17.1-B03, the MODE Mixed, Sharing)

Eclipse版本： Release 4.2.0 Last revised June 8th， 2012

Tuning ago

Eclipse initial configuration file

eclipse.ini

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.200.v20120522-1813
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Dhelp.lucene.tokenizer=standard
-Xms40m
-Xmx512m

Test results before tuning

Average takes about: 10 seconds
The garbage collector total elapsed time 1.710 s, in which:
- Full GC was triggered eight times, took 1.438 s;
- Minor GC was triggered 29 times, time-consuming 272.185 ms;
- Eclipse after running for some time, it will explicitly call System.gc () method to do Full GC.
Loads classes: 8279, takes 7.598 s
JIT compilation time: 1.829 s
Virtual machine with 512MB of memory is allocated for the new generation of 170MB (Eden area for the 136MB and 17MB of two Survivor areas) and 342MB of years old

Eclipse startup process:

After Eclipse starts, running for some time:

Analysis and Tuning

JDK version upgrade

Get free "performance" (here temporarily not be considered).

Class load and compile time optimization

Class loader: bytecode verification optimization. Considering the actual circumstances: Eclipse user very much, which compiled code is reliable, no further bytecode verification at load time.

Optimization measures: add parameters -Xverify:noneto prohibit bytecode verification.

Compile time: None

Adjust the memory settings control the frequency of garbage collection

the first time

Minor GC new generation occurs because the space allocated to the new generation of small lead.

Full GC reasons arising from the analysis GC log:

2.558: [Full GC 2.558: [Tenured: 5029K->6089K(27328K)， 0.0769168 secs] 7919K->6089K(39616K)， [Perm : 16383K->16383K(16384K)]， 0.0769992 secs] [Times: user=0.08 sys=0.00， real=0.08 secs]
4.740: [Full GC 4.740: [Tenured: 9085K->11372K(27328K)， 0.1007947 secs] 13555K->11372K(39680K)， [Perm : 20479K->20479K(20480K)]， 0.1008572 secs] [Times: user=0.08 sys=0.00， real=0.09 secs]
5.853: [Full GC 5.853: [Tenured: 13120K->16847K(27328K)， 0.1368830 secs] 25460K->16847K(39680K)， [Perm : 24575K->24575K(24576K)]， 0.1369769 secs] [Times: user=0.14 sys=0.00， real=0.14 secs]
6.317: [Full GC 6.317: [Tenured: 16847K->17236K(28080K)， 0.1789713 secs] 20615K->17236K(40752K)， [Perm : 28671K->28646K(28672K)]， 0.1791253 secs] [Times: user=0.17 sys=0.00， real=0.17 secs]
7.247: [Full GC 7.248: [Tenured: 19043K->20238K(28728K)， 0.1739436 secs] 20408K->20238K(41720K)， [Perm : 32767K->32767K(32768K)]， 0.1740637 secs] [Times: user=0.17 sys=0.00， real=0.17 secs]
7.928: [Full GC 7.928: [Tenured: 20238K->22897K(33732K)， 0.2087824 secs] 31501K->22897K(48964K)， [Perm : 36863K->36863K(36864K)]， 0.2093529 secs] [Times: user=0.20 sys=0.00， real=0.20 secs]
9.892: [Full GC 9.892: [Tenured: 22897K->25238K(38164K)， 0.2628295 secs] 38655K->25238K(55444K)， [Perm : 40959K->40959K(40960K)]， 0.2629460 secs] [Times: user=0.27 sys=0.00， real=0.27 secs]

Print parameters log

-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xloggc:gc.log

Can be seen from the above, the Full GC 7 times in the last 4 years old Full GC for expansion, expansion to last from 27328K 38164K. From the data, it can be seen three times before Full GC is substituted for a permanent expansion triggered.

From the above analysis it can be concluded

Eclipse started when, Full GC's mostly due to the old and permanent generations resulting from capacity expansion in order to avoid wasting performance, can -Xmsand -XX:PermSizeparameter values are set -Xmxand -XX:PermSizeMaxparameter values, that is the same size is set to reduce the automatic expansion.

Optimization of concrete measures

The new generation is set to 170MB, the new generation avoid frequent expansion of the GC:
the Java heap, permanent generation capacity are fixed at 512MB and 256MB, avoid memory expansion.

eclipse.ini content adjusted

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.200.v20120522-1813
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Dhelp.lucene.tokenizer=standard
-Xverify:none
-Xms512m
-Xmx512m
-Xmn170m
-XX:PermSize=256m

the second time

After tuning operating results, analysis again:

Old Gen curve from the point of view, the old year fixed directly to 342MB, using 25.69MB, and has been very smooth, completely Full GC fishes should not happen. Then the GC log and saw a marked back Full GC System, and FIG GC Time of Last Cause: System.gc (), for the system described explicitly call System.gc ().

Optimization measures:

Removing explicitly call System.gc (), add the parameter -XX:+DisableExplicitGCmasked System.gc ().

Adjusted eclipse.ini content:

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.200.v20120522-1813
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Dhelp.lucene.tokenizer=standard
-Xverify:none
-Xms512m
-Xmx512m
-Xmn170m
-XX:PermSize=256m
-XX:+DisableExplicitGC

After optimization tune

Class load optimization results

Adding parameters -Xverify:none, the class loading time is reduced to from 7.598s 4.665s.

After adjusting the memory control result provided

the first time:

GC logs:

2.845: [GC 2.846: [DefNew: 139264K->7351K(156672K)， 0.0463358 secs] 139264K->7351K(506880K)， 0.0463981 secs] [Times: user=0.05 sys=0.00， real=0.05 secs]
4.581: [GC 4.582: [DefNew: 146615K->16818K(156672K)， 0.0786477 secs] 146615K->16818K(506880K)， 0.0787217 secs] [Times: user=0.08 sys=0.00， real=0.08 secs]
64.279: [Full GC (System) 64.279: [Tenured: 0K->26315K(350208K)， 0.3266376 secs] 127364K->26315K(506880K)， [Perm : 39195K->39195K(262144K)]， 0.3267561 secs] [Times: user=0.31 sys=0.01， real=0.33 secs]

In the parameters adjusted, GC number has been drastically reduced. Figure 1 is a rear starting Eclipse minute monitoring curve occurs only twice Minor GC and 1 Full GC, total elapsed time 451.603ms. Compared to the previous 1.710s, decreased by two times.

the second time:

I do not have the Full GC up.

to sum up

These are just devoted to analysis and tuning process for starting the Eclipse, Eclipse did daily development work on the analysis and tuning.

Reference material

"In-depth understanding of the Java Virtual Machine: JVM advanced features and best practices."

Tuning of the tuning start actual JVM Eclipse