Remember the idea compiler tuning

Objective:

We know that idea is written in Java, so he certainly has a problem with the tuning of the virtual machine, so today we're going to cut it.

The following is the default parameter location in: C:\Program Files\jetbrains\intellij idea 2018.2\bin\idea64.exe.vmoptions

1-xms128m2-xmx756m3-xx:reservedcodecachesize=240m4-xx:+USECONCMARKSWEEPGC5-xx:softreflrupolicymspermb=506-EA7-dsun.io.usecanoncaches=false8-djava.net.preferipv4stack=true9-djdk.http.auth.tunneling.disabledschemes= ""Ten-xx:+Heapdumponoutofmemoryerror One-xx:-O Mitstacktraceinfastthrow

As we can see from here, the heap has a minimum allocation of 128M and a maximum of 756M.

The new generation uses the Parnew collector, which is based on the tag replication algorithm

Used in the old age is the CMS, based on the tag-clearing algorithm.

Before optimization:

We have used two artifacts here. Jvisualvm.exe and Jconsole.exe.

We'll start with idea.

The new generation carried out 56 GC, and the old age carried out 5 full GC. It must be unbearable.

Optimization One:

1-xms1024m 2-xmx1024m 3-xmn350m4-xx:reservedcodecachesize=240m5-xx:+USECONCMARKSWEEPGC6-xx:softreflrupolicymspermb=507-EA8-dsun.io.usecanoncaches=false9-djava.net.preferipv4stack=trueTen-djdk.http.auth.tunneling.disabledschemes= "" One-xx:+Heapdumponoutofmemoryerror A-xx:-Omitstacktraceinfastthrow - 14-verbose:gc15-xx:+printgcdetails16-xx:+printgcdatestamps17-xloggc:gcc.log

The maximum minimum for the set heap is 1024M, and no dynamic expansion is given. and set the Cenozoic to 350M, while logging.

As can be seen, only 7 times of the Cenozoic gc,3 times GC.

I wonder why the old age did not fill up, and there is a lot of space, will happen three times FULLGC? Some of the logs are as follows:

12018-08-20t22:35:57.399+0800:3.963: [cms-concurrent-preclean-start]22018-08-20t22:35:57.399+0800:3.965: [cms-concurrent-preclean:0.002/0.002 secs] [times:user=0.00 sys=0.00, real=0.00secs]32018-08-20t22:35:57.399+0800:3.965: [cms-concurrent-abortable-preclean-start]42018-08-20t22:35:59.457+0800:6.018: [cms-concurrent-abortable-preclean:1.465/2.053 secs] [times:user=6.16 sys=0.52 , real=2.06secs]52018-08-20t22:35:59.458+0800:6.019: [GC (CMS Final Remark) [YG occupancy:167766 K (322560 k)]2018-08-20t22:35:59.458+08 00:6.019: [Rescan (parallel), 0.0669837 secs]2018-08-20t22:35:59.525+0800:6.086: [Weak refs processing, 0.0000425 secs] 2018-08-20t22:35:59.525+0800:6.086: [classUnloading, 0.0054995 secs]2018-08-20t22:35:59.530+0800:6.091: [Scrub symbol table, 0.0064731 secs]2018-08-20t22 : 35:59.537+0800:6.098: [Scrub string table, 0.0004637 secs][1 cms-remark:0k (690176K)] 167766K (1012736K), 0.0803359 secs ] [times:user=0.25 sys=0.00, real=0.08secs]62018-08-20t22:35:59.538+0800:6.099: [cms-concurrent-sweep-start]72018-08-20t22:35:59.538+0800:6.099: [cms-concurrent-sweep:0.000/0.000 secs] [times:user=0.00 sys=0.00, real=0.00secs]82018-08-20t22:35:59.538+0800:6.099: [cms-concurrent-reset-start]92018-08-20T22:35:59.540+0800:6.101: [cms-concurrent-reset:0.002/0.002 secs] [times:user=0.00 sys=0.00, real=0.00secs]Ten2018-08-20t22:36:03.352+0800:9.915: [GC (Allocation Failure) 2018-08-20t22:36:03.352+0800:9.915: [parnew:310560k- >29155k (322560K), 0.0792661 secs] 310560k->47946k (1012736K), 0.0793506 secs] [times:user=0.25 sys=0.02, real= 0.08secs] One2018-08-20t22:36:07.438+0800:14.013: [GC (CMS Initial Mark) [1 cms-initial-mark:18790k (690176K)] 255956K (1012736K), 0.0418642 secs] [times:user=0.22 sys=0.00, real=0.06secs] A2018-08-20t22:36:07.515+0800:14.076: [Cms-concurrent-mark-start]

Because the old age is the use of CMS, we have to analyze under what circumstances CMS will lead to FULLGC.

1: The guarantee fails, that is, in the concurrent purge, there will be a new generation of guarantees come in, if not enough, the early departure full GC.

Scale can be adjusted by-xx:cmsinitiatingoccupancyfraction.

2: Because the CMS is a tag cleanup algorithm, it is bound to generate a lot of fragmentation, resulting in full GC

Can be avoided by adjusting the size of the old age.

But after the above two analysis, and adjusted, found that still will occur FULLGC, and the old age of space is still more special, there is no space, or can not find the problem of continuous space, then why do full GC?

Optimization Two:

1-xms1024m2-xmx1024m3-xmn350m4-xx:reservedcodecachesize=240m5-xx:+USECONCMARKSWEEPGC6-xx:softreflrupolicymspermb=507-EA8-dsun.io.usecanoncaches=false9-djava.net.preferipv4stack=trueTen-djdk.http.auth.tunneling.disabledschemes= "" One-xx:+Heapdumponoutofmemoryerror A-xx:-Omitstacktraceinfastthrow -  --VERBOSE:GC the-xx:+printgcdetails --xx:+Printgcdatestamps --Xloggc:gcc.log - 19-xx:metaspacesize=1024m

Watch the last parameter-xx:metaspacesize=1024m

It can be seen that at this time FULLGC did not occur, the new generation of GC to occur 7 times has completed the start.

Conclusion:

Test, I have tested many times, of course, not like a blog such a simple test. A lot of information, compared to a lot of data.

Before optimization, probably started to carry out more than 50 Cenozoic gc,3-5 times the old age GC.

After optimization, 7 times of the new generation of gc,0 times GC.

The start-up time is about 10s.

Analyze why METASPACEGC will trigger a CMS GC

1 Jdk8:metaspace2In JDK 8, classes metadata are now stored in thenativeHeap3and ThisSpace is called Metaspace. There is someNewFlags added for 4Metaspace in JDK 8: 5-xx:metaspacesize=where is the initial amount of space (the initial6High-water-mark) Allocated for classmetadata (in bytes) so may induce a7 garbage collection to unload classes. The amount is approximate. after the8High-water-mark is first reached, the next high-water-Mark is managed by9 The garbage collectorTen-xx:maxmetaspacesize= where is the maximum amount of space to be allocated for class  One metadata (in bytes). This flag can is used to limit the amount of space AAllocated for classMetadata. This value is approximate. Bydefaultthere - is no limit set. --xx:minmetaspacefreeratio= where is the minimum percentage ofclassMetadata Capacity the avoid a increase in the amount of space -(High-water-mark) allocated for classmetadata that would induce a garbage collection. --xx:maxmetaspacefreeratio= where is the maximum percentage ofclassMetadata Capacity - Free after a GC to avoid a reduction in the amount of space +(High-water-mark) allocated for classmetadata that would induce a garbage collection. -Bydefault class  +Metadata allocation is only limited by the amount of availablenativememory. We Acan use theNewOption Maxmetaspacesize to limit the amount ofnativeMemory atUsed forTheclassmetadata. It is analogous (similar) to MaxPermSize. A garbage collection is induced to collect the dead classloaders -and classes when theclassmetadata usage reaches metaspacesize (12Mbytes on - The 32bit client VM and 16Mbytes on the 32bit server VM with larger sizes on - The 64bit VMs). Set metaspacesize to a higher value to delay the induced -Garbage collections. After an induced garbage collection, theclassMetadata Usage -needed to induce the next garbage collection could be increased.

The method area in the runtime data region in the JVM specification, which is also used in the Hotspot virtual machine as an immortal or immortalized zone, is stored in permanet generation for some class information, constants, static variables, and so on, when the system loads classes, When a class is reflected and a method is called, permanet generation may be full, and a fully GC will be executed if it is not configured to adopt a CMS GC. If the full GC is still not recycled, then the JVM will throw the following error message: Java.lang.OutOfMemoryError:PermGen space to avoid the perm Gen to be filled with a fully GC phenomenon, the method used to increase the perm Gen space or switch to using CMS GC.

That is, if the metaspace is insufficient, the full GC will also be triggered (64 is the default 20.8M on the machine). Then turn it up to defer full GC time.

Resources:

78143285

http://tech.dianwoda.com/2018/01/10/jdk8-de-fullgc-zhi-metaspace/