ECLIPSE Idea Tuning 1

Tuning the JVM for the IDE you use

Log output configuration is performed first

Eclipse Modify eclipse.ini

idea Modify idea.exe.vmoptions

Increase the configuration parameters of the print log

-xx: +printgctimestamps -xx: +printgcdetails -verbose: GC -XLOGGC: Cc_gc.log

After you start the IDE, view the cc_gc.log file

9.818: [GC 9.818: [defnew:139776k->17472k (157248K), 0.1119870 secs] 139776k->18556k (506816K), 0.1122030 secs] [Ti mes:user=0.09 sys=0.02, real=0.11 secs] 14.429: [GC 14.430: [defnew:157248k->17472k (157248K), 0.2153986 secs] 158332k->50602k (506816K), 0.2155784 secs] [ times:user=0.17 sys=0.03, real=0.22 secs] 21.186: [FullGC 21.187: [tenured:33130k->64738k (349568K), 0.3896917 secs] 182739k->64738k (506816K), [P ERM:16384K->16384K (16384K)], 0.3898639 secs] [times:user=0.31 sys=0.03, real=0.39 secs] 28.252: [FullGC 28.252: [tenured:64738k->72853k (349568K), 0.3850680 secs] 113468k->72853k (506816K), [P erm:20479k->20479k (20480K)], 0.3852719 secs] [times:user=0.39 sys=0.00, real=0.38 secs] 30.163: [Full GC 30.163: [tenured:72853k->74842k (349568K), 0.4226417 secs] 104230k->74842k (506816K), [perm:2457 5k->24575k (24576K)], 0.4228340 secs] [times:user=0.41 sys=0.02, real=0.42 secs] 32.836: [Full GC 32.836: [tenured:74842k->65968k (349568K), 0.5620080 secs] 124311k->65968k (506816K), [perm:2867 1k->28645k (28672K)], 0.5622182 secs] [times:user=0.56 sys=0.00, real=0.56 secs] 37.398: [Full GC 37.398: [tenured:65968k->68840k (349568K), 0.4841606 secs] 134377k->68840k (506816K), [perm:3276 7k->32767k (32768K)], 0.4843980 secs] [times:user=0.48 sys=0.00, real=0.49 secs] 44.791: [GC 44.791: [defnew:139776k->6749k (157248K), 0.0712144 secs] 208616k->75589k (506816K), 0.0713880 secs] [T imes:user=0.06 sys=0.00, real=0.07 secs] 46.151: [Full GC 46.151: [tenured:68840k->87682k (349568K), 0.4460944 secs] 151814k->87682k (506816K), [perm:3685 7k->36857k (36864K)], 0.4462617 secs] [times:user=0.44 sys=0.00, real=0.45 secs] 47.559: [Full GC 47.559: [tenured:87682k->90045k (349568K), 0.3395155 secs] 180158k->90045k (506816K), [perm:4095 9k->40959k (40960K)], 0.3396347 secs] [times:user=0.34 sys=0.00, real=0.34 secs] 49.159: [Full GC 49.159: [tenured:90045k->85954k (349568K), 0.4153938 secs] 214420k->85954k (506816K), [perm:4505 5k->45015k (45056K)], 0.4155009 secs] [times:user=0.41 sys=0.00, real=0.41 secs] 50.697: [GC 50.697: [defnew:139776k->2972k (157248K), 0.0180432 secs] 225730k->88927k (506816K), 0.0181231 secs] [T imes:user=0.02 sys=0.00, real=0.02 secs] 51.128: [Full GC 51.128: [tenured:85954k->89721k (349568K), 0.2832516 secs] 143886k->89721k (506816K), [perm:4915 1k->49151k (49152K)], 0.2833462 secs] [times:user=0.28 sys=0.00, real=0.28 secs] 51.979: [GC 51.979: [defnew:139776k->2718k (157248K), 0.0172579 secs] 229497k->92440k (506816K), 0.0173547 secs] [T imes:user=0.01 sys=0.00, real=0.02 secs] 52.525: [GC 52.525: [defnew:142494k->5601k (157248K), 0.0199793 secs] 232216k->95322k (506816K), 0.0200686 secs] [T imes:user=0.03 sys=0.00, real=0.02 secs] 54.030: [FullGC 54.030: [tenured:89721k->100007k (349568K), 0.7484057 secs] 211409k->100007k (506816K), [perm:53248k->53248k (53248K)], 0.7486056 secs] [times:user=0.75 sys=0.00, real=0.75 secs] 56.711: [GC 56.711: [defnew:139776k->3470k (157248K), 0.0305333 secs] 239783k->103478k (506816K), 0.0306645 secs] [ times:user=0.03 sys=0.00, real=0.03 secs] 57.267: [GC 57.267: [defnew:143246k->5452k (157248K), 0.0320053 secs] 243254k->105460k (506816K), 0.0321151 secs] [ times:user=0.03 sys=0.00, real=0.03 secs] 58.240: [GC 58.241: [defnew:145228k->4416k (157248K), 0.0507719 secs] 245236k->104424k (506816K), 0.0509615 secs]

You'll see many times full gc and more MINOR GC

The fullgc of the JVM will actually cause your app to pause, so it will give you a false impression of being stuck.

While MINOR GC performs garbage collection while executing your app, it has less impact on your app , but the same efficiency is not as thorough as FULLGC .

The cause of FULLGC may be the old age (tenured) full, the persistent generation (Perm) Full , or explicitly call System.GC ()

As you can see here, Perm is full. As to what is the old generation of the generation of persistent generations, to start from the implementation of virtual machines began to talk about ... A bit long, or look at the << in-depth understanding of Java virtual machine >> , this write in layman's.

Since it is full, it is easy to increase the capacity of the last generation. So add a bit of parameter

# the same size as the maximum for a durable generation, avoiding redistribution -xx: permsize=512m # Persistent generation Maximum value -xx: maxpermsize=512m

Restart the IDE, view the print log, you will find that the full GC log is less, but occasionally appear, but the minor GC is still much the same, how to remove the Damned GC ?

13.286: [GC 13.286: [defnew:279616k->34944k (314560K), 0.2190107 secs] 279616k->48613k (1013632K), 0.2192137 secs] [times:user=0.17 sys=0.05, real=0.22 secs] 48.551: [GC 48.551: [defnew:314560k->28346k (314560K), 0.6644487 secs] 328229k->70837k (1013632K), 0.6647003 secs] [times:user=0.36 sys=0.23, real=0.66 secs] 69.702: [GC 69.702: [defnew:307962k->19605k (314560K), 0.3614997 secs] 350453k->88787k (1013632K), 0.3617434 secs] [times:user=0.36 sys=0.00, real=0.36 secs] 78.648: [GC 78.648: [defnew:299221k->10228k (314560K), 0.2022102 secs] 368403k->97761k (1013632K), 0.2023637 secs] [times:user=0.19 sys=0.00, real=0.20 secs] 85.375: [GC 85.375: [defnew:289844k->12827k (314560K), 0.1320774 secs] 377377k->100360k (1013632K), 0.1322965 secs ] [times:user=0.12 sys=0.00, real=0.13 secs] 96.130: [GC 96.130: [defnew:292443k->23240k (314560K), 0.1398189 secs] 379976k->110773k (1013632K), 0.1399750 secs ] [times:user=0.14 sys=0.00, real=0.14 secs] 101.912: [GC 101.912: [defnew:302856k->18367k (314560K), 0.1574988 secs] 390389k->115683k (1013632K), 0.1576590 SE CS] [times:user=0.16 sys=0.00, real=0.16 secs] 103.306: [Full GC (System) 103.306: [tenured:97315k->113265k (699072K), 0.9300948 secs] 167525k->113265k (1013632K ), [perm:64945k->64945k (524288K)], 0.9303121 secs] [times:user=0.92 sys=0.02, real=0.93 secs] 110.229: [GC 110.229: [defnew:279616k->5932k (314560K), 0.0517919 secs] 392881k->119198k (1013632K), 0.0519378 sec S] [times:user=0.05 sys=0.00, real=0.05 secs] 111.312: [GC 111.312: [defnew:285548k->5365k (314560K), 0.0235290 secs] 398814k->118631k (1013632K), 0.0236321 secs] [times:user=0.03 sys=0.00, real=0.02 secs] 120.657: [GC 120.657: [defnew:284981k->8851k (314560K), 0.0674546 secs] 398247k->122116k (1013632K), 0.0676027 sec S

Increase the size of the young generation is good, the corresponding parameters are as follows

# Initial Heap Size -xms1024m # Maximum Heap Size -xmx1024m # Young Generation Size -xmn512m

So the initial configuration is good, if it is Eclipse , you will have some obvious start-up time, but idea in addition to the log there are more obvious changes, actually do not feel very big difference. In other words ... You know

Of course , the above is the initialization, that is, the Java object Life, and the Java object dead things ? Depends on the new generation of Java , the old age recovery algorithm and the implementation of the problem of recycling. Interested can look at the previous recommended book.

The reference link also has a specific explanation of the relevant parameters

Ps: This optimization configuration is only a few optimizations to start the IDE , if the development use can be modified to -server , and develop garbage collection mechanism and other parameters

Recommended Links:

JAVA6JVM parameter Options Daquan

Explain blog