Java Session 10

How Garbage collection works?• Java manages memory automatically

• The Garbage collector is part of the Java virtual machine

• Objects referenced by java variables are created in heap memory

• As long as any variable references an object, it is retained.

• When all references expire, the object is eligible to be garbage collected.

• We can explicitly expire persistent objects by setting it to null

• Variables local to function or code block expire when function is complete.

• How Garbage collection works :

The garbage collector runs on its own thread. Mark and sweep approach

When garbage collector identifies a de-referenced object, it can destroy it and reclaim memory

You as the programmer cannot force garbage collection

Methods System.gc() and Runtim.gc() can request garbage collection, but there is no guarantee it will happen

If no memory is available for newly requested object, JVM throws OutOfMemoryError.

• Tips for managing memory : Use command line options to manage amount of available heap memory

• java –Xms256m HelloWorld initial heap size

• Java –Xmx256m HelloWorld Maximum heap size

• Java –Xmn256m HelloWorld Heap size for young generation objects.

How Garbage collection works?

Java (JVM) Memory Types• Heap Memory : Heap memory is also called as shared memory. As this is the place where multiple threads will

share the same data. The heap will be created at JVM startup and the size can be static or dynamic. The JVM specification mandates a Garbage Collection mechanism for reclaiming the memory of an object on the Java heap. The implementation of the Garbage Collector is not specified, but it is not allowed to provide the programmer with an explicit mechanism for deallocating the memory of an object.

• Non-heap Memory : It comprises of ‘Method Area’ and other memory required for internal processing. So here the major player is ‘Method Area’.

• Method Area : The method area is responsible for storing class information. The Class-Loader will load the bytecode of a class and will pass it to the JVM. The JVM will generate an internal class representation of the bytecode and store it in the method area. The internal representation of a class will have the following data areas:

i. Runtime Constant Pool Numeric constants of the class of types int, long, float or double, String-constants and symbolic references to all methods, attributes and types of this class.

ii. Method CodeThe implementation (code) of all methods of this class including constructors etc.

iii. Attributes A list of all named attributes of this class.

iv. FieldsValues of all fields of this class as references to the Runtime Constant Pool.

• Memory Pool : Memory pools are created by JVM memory managers during runtime. Memory pool may belong to either heap or non-heap memory.

• Runtime Constant Pool : A run time constant pool is a per-class or per-interface run time representation of the constant_pool table in a class file. Each runtime constant pool is allocated from the Java virtual machine’s method area.

• Java Stacks or Frames : Java stacks are created private to a thread. Every thread will have a program counter (PC) and a java stack. PC will use the java stack to store the intermediate values, dynamic linking, return values for methods and dispatch exceptions. This is used in the place of registers.

Memory Generations• HotSpot VM’s garbage collector uses generational garbage collection. It separates the JVM’s memory into and they

are called young generation and old generation.

• Young Generation : Young generation memory consists of two parts, Eden space and survivor space. Shortlived objects will be available in Eden space. Every object starts its life from Eden space. When GC happens, if an object is still alive and it will be moved to survivor space and other dereferenced objects will be removed.

• Old Generation – Tenured and PermGen : Old generation memory has two parts, tenured generation and permanent generation (PermGen). PermGen is a popular term. We used to error like PermGen space not sufficient. GC moves live objects from survivor space to tenured generation. The permanent generation contains meta data of the virtual machine, class and method objects.

• Local Variables are stored in Frames during runtime.

• Static Variables are stored in Method Area.

• Arrays are stored in heap memory.

• Errors :

Javadoc of java.lang.OutOfMemoryError : Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

In the heap we get an OutOfMemoryError, if the garbage collector cannot reclaim enough memory for a new object. In such situation the Sun HotSpot JVM shows this error message: Exception in thread "main": java.lang.OutOfMemoryError: Java heap space

if the application tries to create an array on the heap that is bigger than the total heap size. error can be : Exception in thread "main": java.lang.OutOfMemoryError: Requested array size exceeds VM limit

If there is not enough memory in the method area for creating a new class, the Sun HotSpot implementation gets an error in the permanent generation:Exception in thread "main": java.lang.OutOfMemoryError: PermGen space

• If there are too many threads in the JVM and there is not enough memory left to create a new thread. I’ve seen below error because the memory limits of a process have been reached (especially in 32bit operating systems, e.g. on Windows 32bit it is 2GB) or the maximum number of file handles for the user that executes the java process has been reached. Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

• Memory allocation error on a native stack (JNI method call) : Exception in thread "main": java.lang.OutOfMemoryError: <reason> <stacktrace> (Native method)

• It is also interesting that a memory allocation error on the JVM stack (too many frames on the stack) does not throw an Java OutOfMemory error but as the JVM specification mandates: java.lang.StackOverflowError.

• If there is not enough memory left on the operating system level – which is normally true if other processes are using all of the available memory or the swap space is configured too small. Error: Exception in thread "main": java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?

Java Memory Leaks• In Java objects get generated on the heap and live on as long as they are referenced. The garbage

collector checks during it GC-phases if the object is still referenced – and does mark it as “garbage” and clean it up later when this is no longer the case (the actual behaviour differs for different gc-algorithms, like the Copying Collectors or Garbage-First, but is not of importance for understanding liveness). But not every reference is important for surviving, but only so called GC root references. Especially when understanding Memory Leaks, GC roots are a central concept to identify the important references to an object. Garbage Collector Roots are special objects which do not have incoming references and are responsible for keeping referenced objects alive. When an object cannot be reached directly or indirectly from a GC root, it will be marked as “unreachable” and made eligible for garbage collection. Simply speaking, there are three kinds of GC roots:

Temporary variables on the stack of a thread

Static members of a loaded class

Special native references from JNI

• Usually there are tree types of issues with Java OutOfMemoryError problems in heap memory:

Objects, which can be reached via a GC root reference, but are actually no longer used by application code. Those are called Java Memory Leaks.

Too many or too large objects. So there is not enough heap available for the application to execute. Usually happens when there are large objects kept in cache like structures.

Too many temporary objects. So there is just for a short time not enough memory. Usually happens in load scenarios where many temporary objects are used.

Ex: http://ideone.com/1QowAQ

Java Memory Leaks• Java Memory Leaks occur when objects still have a GC root reference, but are not actually used

anymore. Those “Loitering Objects” stay around for the whole life of the JVM. If the application is creating those “dead objects” on and on, the memory will be filled up and eventually result in a java.lang.OutOfMemoryError. Typical causes are static collections, which are used as a kind of cache. Usually objects are added, but never removed (Let’s face it: How often have you used add() and put() and how often used remove() methods?). Because the objects are referenced by the static collection, they cannot be freed up anymore, as the collection has a GC root reference via the classloader.

• Depending on the creation frequency and the object size, as well as the size of the Java heap, the OutOfMemoryError occurs sooner or later. Especially those “creeping memory leaks” can be found in many applications, but are usually “ignored” by:

• Using large heaps to delay the error. Happens frequently nowadays, as the old 32bit memory limit has vanished through the usage of 64 bit JVMs.

• Restarting the application server during the night. This “resets” the memory usage. If the memory leak takes longer than 24 hours to become severe, this will help.

• But both variants are dangerous, as they have negative impact on the system performance and are heavily influenced by the system usage. A change in usage or more “traffic” can produce the error faster than expected. Garbage collection times also have a negative effect on the application performance, as the increasing “tenured generation” causes longer “Mark”-Phases during garbage collection, resulting in longer pause times, which can be observed as system hangs.

• Refer: https://gist.github.com/rajeevprasanna/04b4c9322a5245877c1f