While i was reading the latest Java Magazine (July-August 2013), i came across a topic namely, “Adaptive Size Policy” with regards to one of the important components in JVM, garbage collection.
I researched on this topic and this blog post is my attempt to explain this in some details with good references for follow up reading.
Before going on to explain “Adaptive Size Policy”, i need to cover certain basics in the field of garbage collection. I will be covering this blog under such sub-topic for easy understanding and reading.
JVM Heap in General
JVM heap, aka heap, is divided into two regions, called as generation, namely
- Young Generation
- Old Generation
The Young generation region is further divided into sub-regions, namely
- Survivor Space 1
- Survivor Space 2
This is how it works when an object is created:
- The object will be created in Eden and it could be destroyed there itself
- If the Eden region is full, the object is pushed to Survivor Space 1
- If the Survivor space 1 is full, the object is pushed to Survivor Space 2
- The objects which are not destroyed in Survivor Space 2 are retired to the Old Generation region of the heap
To tweak the heap size commonly used Java options as -Xms and -Xmx. You can get a complete list of -X commands that you can use with respect to Java Heap Size, please run the command java -X. Below screenshot shows the various commends that can be used.
Java Garbage Collection in General
Most of the programming language including Java has a very important feature of automatic memory management, also known as “Garbage Collection”. Objects created during execution of a program, at various stages becomes unreachable and are considered as “garbage”. Over a period of time for managing memory, these garbage is removed and the space is regained for useful staff. Java has very good garbage collection and over a period of time, with some very good engineers working on it, using various algorithms, have made significant progress and enhancement this all important feature.
The core component in the Java SE platform is JVM (Java Virtual Machine). In the case of Oracle JVM, its called as “Oracle’s Hotspot JVM”. We will discuss garbage collection with respect to this Hotspot JVM as GC (Garbage Collection) methodologies differ according to the JVM being used.
Garbage collection is one of the biggest benefit which the Java language provides. If used in a proper manner it will be really beneficial, but if not used cautiously, it can doom your application big time. Some of the considerations with respect to garbage collection which have to be kept in mind are the following:
- JVM Pause – The time taken by the JVM to do the GC during which the JVM pauses
- Throughput – The time interval between successive GC
Our goal as an application tuner is to minimize the JVM pause and maximize throughput. There is no hard and fast rule that you can reply on to do this. It comes with experience and the environment in which your JVM/application functions, which will interfere to a greater extend.
There are various GC modes which are possible to be configured using various JVM commend line options. Having said that, these JVM options configured is dependent on various components like the hardware you are running, JVM version etc. to name a few. The default GC mode also depends on the JVM vendor. The various GC modes with respect to Hotspot JVM is as detailed below:-
As the name suggests it is executed by a single thread and requires a complete stop on all the processes carried out by JVM during the execution. The JVM switch for this is specified as -XX:+UseSerialGC
As the name suggests the collection is parallelized between multiple threads. This also requires the entire JVM operations to be stopped/deferred but during to parallelism, the time required will be reduced to a greater extend. The JVM switch for this is specified as -XX:+UseParallelGC. In modern days due to availability of multicore/multiprocessor this has become more of a norm.
Parallel Old GC
Incremental advancement over Parallel GC mode. I don’t want to go into much more detail, as this post is a head start for beginners to get a primer on GC. The JVM switch for this is specified as -XX:+UseParallelOldGC
Adaptive Size Policy
A special mode of Parallel Scavange in which the JVM automatically adapts and adjust the various heap sizes and does the GC. Might sound a big scary as you might feel that there isn’t much control in overall space allocation by JVM. But IMHO, the java engineers have put lots of effort and experience building this and they shouldn’t be taken as complete wrong and we should have fairly good confidence in using this switch as well. The JVM switch for this is specified as -XX:+UseAdaptiveSizePolicy
Concurrent Mark Sweep (CMS)
Its a low pause collector and the way by which it handles this by using different algorithms for collecting the various heap regions. The JVM switch for this is specified as -XX:+UseConcMarkSweepGC
CMS incremental mode
In this the CMS competes with the CPU cores to perform the GC. The GC thread and application thread works in parallel and in modern day hardware IMHO this is good option. The JVM switch for this is specified as -XX:+CMSIncrementalMode
G1 Garbage Collector
New generation collection mode introduced as part of JVM 1.6. For more details you can find the link to a blog by Alexey Ragozin. The JVM switch for this is specified as -XX:+UseG1GC
Adaptive Size Policy in Detail
Now coming to the main point in this blog, “Adaptive Size Policy”. Since now you have a good idea of the various basics with respect to JVM Heap and JVM GC options, I would be able to explain this concept much easily.
By defining adaptive size policy in a JVM, you are commanding the JVM to adapt itself to the surrounding environment by dynamically re-sizing the heap and its regions so as to attain certain goals already set as follows:
- Minimize the footprint created by the heap
- Adhere to the maximum garbage collection JVM pause as desired
- Adhere to the minimum garbage collection throughput goal as desired
As detailed in the earlier section, to enable this set the JVM switch as follows:
To set the desired policy values, you can use the following switches:
-XX:MxGCPauseMillis=nnn – Tells the VM that maximum of nnn milliseconds on less is desired
-XX:GCTimeRatio=nnn – The ratio of GC time to application time
Ideally if you specify the -Xms value to be equal to -Xmx, adaptive size policy is nullified. In cases this might be desirable, but in most of the cases believing the engineers behind this algorithm will surely make your application perform faster and in no case IMHO this should be done whereby a feature is nullified as good amount of research and experience is employed while designing and developing it.
Its good to not that options beginning with -X are non-standard, means, need not be supported by all the VM vendors in the market and these are subject to change according to vendor discretion. The options beginning with -XX are non-stable and similar to -X, these are subject to change without notice.
GURU’s with regards to this topic – References
In simple words – http://www.informit.com/guides/content.aspx?g=java&seqNum=27
Java Hotspot VM options – http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
Complete list of -XX options for Java JVM – http://stas-blogspot.blogspot.co.uk/2011/07/most-complete-list-of-xx-options-for.html
That’s all folks. Thanks once again for all the reference materials, which helped to me learn these concepts and write this blog.
Page Visitors: 3670