- gen0(s) – young gen collection time, excluding gc_prologue & gc_epilogue.
- gen0t(s) – young gen collection time, including gc_prologue & gc_epilogue
- gen0usr(s) – young gen collection time in cpu user secs
- gen0sys(s) – young gen collection time in cpu sys secs
- gen1i(s) – train generation incremental collection
- gen1t(s) – old generation collection/full GC
- cmsIM(s) – CMS initial mark pause
- cmsRM(s) – CMS remark pause
- cmsRS(s) – CMS resize pause // rarely look. Probably we set OG at fixed size
- GC(s) – all stop-the-world GC pauses
- cmsCM(s) – CMS concurrent mark phase // don’t care
- cmsCP(s) – CMS concurrent preclean phase // don’t care
- cmsCS(s) – CMS concurrent sweep phase // don’t care
- cmsCR(s) – CMS concurrent reset phase // don’t care
- alloc(MB) – object allocation in MB (approximate***)
- promo(MB) – object promotion in MB (approximate***)
- used0(MB) – young gen used memory size (before gc)
- used1(MB) – old gen used memory size (before gc)
- used(MB) – heap space used memory size (before gc) (excludes perm gen)
- commit0(MB) – young gen committed memory size (after gc)
- commit1(MB) – old gen committed memory size (after gc)
- commit(MB) – heap committed memory size (after gc) (excludes perm gen)
- apptime(s) – amount of time application threads were running
- appstop(s) – amount of time application threads were stalled
- safept(s) – amount of time the VM spent at safepoints (app threads stopped)
Tag Archives: GC
Here are some commonly used JVM parameters that every application developer should review, some may be appropriate for your application, some may not.
This post is a quick reference for these parameters, please refer to the official java docs for complete technical documentations.
e.g. -Xms16g -Xmx16g
The min and max of your heap size. When you set them the same, you fixed the size which helps avoid any change in real time, but of course you want to make sure you don’t waste the size. NOTE: If you use a big heap ( or are using large page size ( default is 4KB ), consider using -XX:+AlwaysPreTouch also.
When you set this, in your GC log you will start seeing entries like
- Total time for which application threads were stopped: 0.0002480 seconds
- Total time for which application threads were stopped: 0.0001090 seconds
It reports the duration of time when your application is paused due to any kind of GC activity, and is used as another meter to measure your application throughput of the system CPU.
It prints the GC in details in old gen, young gen and perm gen. Your gc log won’t be very useful without this.
It prints the timestamp of GC event, without this, the only timestamp would be the time since the application start.
This reports the tenuring statistics (how old the objects are) and the desired threshold of when objects will be promoted. This information gives you insight of how long your application may be holding on to objects.
-XX:NewSize -XX:MaxNewSize (or use -XX:NewRatio )
e.g. -XX:NewSize=4096m -XX:MaxNewSize=4096m
The min and max size of young gen. Alternatively, you can use NewRatio to specify the size of the young gen relative to the size of the entire heap. e.g. -XX:NewRatio=4 means 1GB will be designated as young gen in a 4GB heap (where old gen is about 3GB + perm gen).
The young gen is comprised of eden space and 2 survivor spaces, the survivor ratio specifies the size of the survivor space relative to the eden space. e.g. if you have a 4GB young gen and survivor ratio is 2, then your eden space is 2GB and each of your survivor space has 1GB in size. In other words, your survivor space size = ( size of young gen / ( SurvivorRatio + 2 ) ). The ratio can be tuned for your application, the smaller the survivor space, the fewer iteration the objects can be tenured which could lead to more promotions.
Use the concurrent mark sweep garbage collector. This collector is responsible for collecting in old gen and will run in parallel to young gen parallel collector. Its IM ( initial mark ) and RM ( remark ) are the operations that will pause the application. Other times reported in the GC such as CS ( concurrent sweep ) are non-pausing so they won’t really affect your JVM as much as IM and RM.
Assuming you already have UseConcMarkSweepGC, this tells the CMS (Concurrent Mark Sweep Collector) in the old gen to start collection process when old gen is 85% full, if it hasn’t already. Note that CMS could start before old gen reaches 85% even if you have already set the CMSInitiatingOccupancyFraction. CMS has its own logic to decide when to start. If you absolutely wants CMS to start only at 85%, then set also -XX:+UseCMSInitiatingOccupancyOnly. The default is 65%.
Consider using this when you have a big heap or are using large page. It pretouchs and set zero all the pages you have allocated during the initialization of your application. Normally a page is touched when it is used, but in the cases where you have big heap or big page size, this may increase your startup time, but is probably better than doing the pretouch in run time with performance impact.
This will allow CMS to also do some garbage collection in the permanent generation. If you use this option, be sure to also use UseConcMarkSweepGC. This has been seen to solve an apparent perm gen memory leak in Voltron: (described in this page: Perm Gen memory increases)
A feature referred to here as ergonomics was introduced in J2SE 5.0. The goal of ergonomics is to provide good performance with little or no tuning of command line options by selecting the
- garbage collector,
- heap size,
- and runtime compiler
Generational Collection : Young and tenure Gen
Collectors in Young Gen :
minor collections :
serial collectors – applications with small data set and single processors
throughput collectors – Applications that have medium to large data sets.
Generations in Heap / Garbage collection :
Yong Generation :
Tenured Generation :
Permanent Generation :
A third generation closely related to the tenured generation is the permanent generation which holds data needed by the virtual machine to describe objects that do not have an equivalence at the Java language level. For example objects describing classes and methods are stored in the permanent generation.
Performance Considerations for Garbage Collection :
- Throughput is the percentage of total time not spent in garbage collection, considered over long periods of time. Throughput includes time spent in allocation (but tuning for speed of allocation is generally not needed).throughput is inversely proportional to the amount of memory available. Total available memory is the most important factor affecting garbage collection performance.
- Pauses are the times when an application appears unresponsive because garbage collection is occurring.
- Memory Footprint
- Promptness is the time between when an object becomes dead and when the memory becomes available
some examples / scenarios :
Large Yong Generation (size) – maximize throughput – at the expense of higher footprint, promptness and pause times.
Anatomy of GC log :
[GC 325407K->83000K(776768K), 0.2300771 secs]
GC – Minor GC
325407K->83000K – size of live objects before and after garbage collection, respectively. After minor collections the size includes some objects that are garbage (no longer alive) but that cannot be reclaimed. These objects are either contained in the tenured generation, or referenced from the tenured or permanent generations.
(776768K) – the amount of space usable for java objects without requesting more memory from the operating system. ( excludes space allocated to one of the survivor spaces and permanent gen )
[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]
[DefNew: 64575K->959K(64576K), 0.0457646 secs] – indicates space revovered by minor collection in young Gen and available space in Yong Gen ( not it was only minor collection which was invoked during this cycle )
196016K->133633K(261184K) – indicates the overall space made available in the heap. and corresponding total time ( this is time taken by young gen minor collection plus some overhead )
-XX:+PrintGCTimeStamps will add a time stamp at the start of each collection. This is useful to see how frequently garbage collections occur.
111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]
111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]
Sizing Generations :
-Xms – Committed Space , this is space is allocated at the initialization of JVM
Difference between -Xmx and -Xms – is the virtual space ( Setting
-Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice. )
MinHeapFreeRatio and MaxHeapFreeRatio – These two ratios help in shrinking and expanding the heap size across the generations within the bounds of Xms and Xmx based on the ratio. For example if MinHeapFreeRatio is set to 40 (or 40%) , the generation will be expanded to maintain 40% free space as the heap is filled up.
XX:NewRatio=3 means that the ratio between the young and tenured generation is 1:3. In other words, the combined size of the eden and survivor spaces will be one fourth of the total heap size. ( Note : Increase the young generation size as you increase the number of processors, since allocation can be parallelized.)
SurvivorRatio – can be used to tune the size of the survivor spaces, but this is often not as important for performance. For example,
-XX:SurvivorRatio=6 sets the ratio between eden and a survivor space to 1:6. In other words, each survivor space will be one sixth the size of eden, and thus one eighth the size of the young generation (not one seventh, because there are two survivor spaces).
Concepts in GC :
App Stops :
The only non-GC case that I know of that brings threads to a safepoint is JIT-related (replacing compiled code with interpreted). One question that I would have would be if this was application-specific thing or if we see the safepoint issues elsewhere, in which case we might be able to ignore them. 33 minutes seems like it’s a long time in to be doing any deoptimization, unless there was a lot of dynamic codegen going on (in which case, stop doing that since it’s slow). That seems unlikely as well, since while the server compiler is more aggressive, it’s not so aggressive that it would be willing to deoptimize that frequently (I’d expect it to keep things in interpreted mode rather than compile if it was doing it that often).