Java (JVM) Memory Model - Memory Management in Java
Java (JVM) Memory Model - Memory Management in Java
Understanding JVM Memory Model, Java Memory Management is very important if you want to understand
the working of Java Garbage Collection. Today we will look into memory management in java, different parts
of JVM memory and how to monitor and perform garbage collection tuning.
As you can see in the above image, JVM memory is divided into separate parts. At broad level, JVM Heap
memory is physically divided into two parts – Young Generation and Old Generation.
Most of the newly created objects are located in the Eden memory space.
When Eden space is filled with objects, Minor GC is performed and all the survivor objects are moved to
one of the survivor spaces.
Minor GC also checks the survivor objects and moves them to the other survivor space. So at a time,
one of the survivor spaces is always empty.
Objects that are survived after many cycles of GC, are moved to the Old generation memory space.
Usually it’s done by setting a threshold for the age of the young generation objects before they become
eligible to promote to Old generation.
Since Young generation keeps short-lived objects, Minor GC is very fast and the application doesn’t get
affected by this.
However Major GC takes longer time because it checks all the live objects. Major GC should be minimized
because it will make your application unresponsive for the garbage collection duration. So if you have a
responsive application and there is a lot of Major Garbage Collection happening, you will notice timeout errors.
The duration taken by garbage collector depends on the strategy used for garbage collection. That’s why it’s
necessary to monitor and tune the garbage collector to avoid timeouts in the highly responsive applications.
Perm Gen is populated by JVM at runtime based on the classes used by the application. Perm Gen also
contains Java SE library classes and methods. Perm Gen objects are garbage collected in a full garbage
collection.
Garbage Collector is the program running in the background that looks into all the objects in the memory and
find out objects that are not referenced by any part of the program. All these unreferenced objects are deleted
and space is reclaimed for allocation to other objects.
1. Marking: This is the first step where garbage collector identifies which objects are in use and which ones
are not in use.
2. Normal Deletion: Garbage Collector removes the unused objects and reclaims the free space to be
allocated to other objects.
3. Deletion with Compacting: For better performance, after deleting unused objects, all the survived
objects can be moved to be together. This will increase the performance of allocation of memory to
newer objects.
There are two problems with simple mark and delete approach.
1. First one is that it’s not efficient because most of the newly created objects will become unused
2. Secondly objects that are in-use for multiple garbage collection cycle are most likely to be in-use for
future cycles too.
The above shortcomings with the simple approach are the reason that Java Garbage Collection is
Generational and we have Young Generation and Old Generation spaces in the heap memory. I have
already explained above how objects are scanned and moved from one generational space to another based
on the Minor GC and Major GC.
1. Serial GC (-XX:+UseSerialGC): Serial GC uses the simple mark-sweep-compact approach for young
and old generations garbage collection i.e Minor and Major GC.
Serial GC is useful in client-machines such as our simple stand-alone applications and machines with
smaller CPU. It is good for small applications with low memory footprint.
Parallel Garbage Collector is also called throughput collector because it uses multiple CPUs to speed
up the GC performance. Parallel GC uses single thread for Old Generation garbage collection.
3. Parallel Old GC (-XX:+UseParallelOldGC): This is same as Parallel GC except that it uses multiple
threads for both Young Generation and Old Generation garbage collection.
CMS collector on young generation uses the same algorithm as that of the parallel collector. This
garbage collector is suitable for responsive applications where we can’t afford longer pause times. We
can limit the number of threads in CMS collector using -XX:ParallelCMSThreads=n JVM option.
Garbage First Collector doesn’t work like other collectors and there is no concept of Young and Old
generation space. It divides the heap space into multiple equal-sized heap regions. When a garbage
collection is invoked, it first collects the region with lesser live data, hence “Garbage First”.
jsat
We can use jstat command line tool to monitor the JVM memory and garbage collection activities. It ships
with standard JDK, so you don’t need to do anything else to get it.
For executing jstat you need to know the process id of the application, you can get it easily using below
command
So the process id for my java application is 9582. Now we can run jstat command as shown below.
The last argument for jstat is the time interval between each output, so it will print memory and garbage
collection data every 1 second.
S0C and S1C: This column shows the current size of the Survivor0 and Survivor1 areas in KB.
S0U and S1U: This column shows the current usage of the Survivor0 and Survivor1 areas in KB. Notice
that one of the survivor areas is empty all the time.
EC and EU: These columns show the current size and usage of Eden space in KB. Note that EU size is
increasing and as soon as it crosses the EC, Minor GC is called and EU size is decreased.
OC and OU: These columns show the current size and current usage of Old generation in KB.
PC and PU: These columns show the current size and current usage of Perm Gen in KB.
YGC and YGCT: YGC column displays the number of GC event occurred in young generation. YGCT
column displays the accumulated time for GC operations for Young generation. Notice that both of them
are increased in the same row where EU value is dropped because of minor GC.
FGC and FGCT: FGC column displays the number of Full GC event occurred. FGCT column displays
the accumulated time for Full GC operations. Notice that Full GC time is too high when compared to
young generation GC timings.
GCT: This column displays the total accumulated time for GC operations. Notice that it’s sum of YGCT
and FGCT column values.
The advantage of jstat is that it can be executed in remote servers too where we don’t have GUI. Notice that
sum of S0C, S1C and EC is 10m as specified through -Xmn10m JVM option.
Just run jvisualvm command in the terminal to launch the Java VisualVM application. Once launched, you
need to install Visual GC plugin from Tools -< Plugins option, as shown in below image.
After installing Visual GC, just open the application from the left side column and head over to Visual GC
section. You will get an image of JVM memory and garbage collection details as shown in below image.
Java Garbage Collection Tuning
Java Garbage Collection Tuning should be the last option you should use for increasing the throughput of
your application and only when you see drop in performance because of longer GC timings causing application
timeout.
If you see java.lang.OutOfMemoryError: PermGen space errors in logs, then try to monitor and
increase the Perm Gen memory space using -XX:PermGen and -XX:MaxPermGen JVM options. You might
also try using -XX:+CMSClassUnloadingEnabled and check how it’s performing with CMS Garbage
collector.
If you see a lot of Full GC operations, then you should try increasing Old generation memory space.
Overall garbage collection tuning takes a lot of effort and time and there is no hard and fast rule for that. You
would need to try different options and compare them to find out the best one suitable for your application.