The Java programming language is object-oriented and includes automatic garbage collection. Garbage collection is the process of reclaiming memory taken up by unreferenced objects.
Memory Management, Java and Impact on Application Servers
The task of memory management that was always challenging with compiled object-oriented languages such as C++. On the other hand, Java is an interpretive language that takes this memory management out of the hands of developers and gives it directly to the virtual machine where the code will be run. This means that for best performance and stability, it is critical that the Java parameters for the virtual machine be understood and managed by the Application Server deployment team. This section will describe the various parts of the Java heap and then list some useful parameters and tuning tips for ensuring correct runtime stability and performance of Application Servers.
Java Virtual Machines
The Java specification as to what is “standard” for a given release is written and maintained by the JavaSoft division of Sun Microsystems. This specification is then delivered to other JVM providers (IBM, HP, etc). JavaSoft provides the standard implementation on Windows, Solaris, and LINUX. Other platforms are required to deliver the code functionality but their JVM options can be different. Java options that are preceded with “-X” or “-XX” are typically platform-specific. That being said, many options are used on all platforms. One must read in detail the README notes from the various releases on various platforms to be kept up-to-date with the variations. This guide will mention the most critical ones and distinguish between those which are implemented on most platforms and those which are platform-specific.
The Java Heap
The Java heap is divided into three main sections: Young Generation, Old Generation and the Permanent Generation as shown in the figure below.
Also, not shown here, is another area called the Code Cache which is typically about 50Mb in Size.
HotSpot VM
The HotSpot VM is the garbage collector that comes with the JavaSoft virtual machine. Its specification is delivered to all JVM providers (HP, IBM, BEA, etc) and the standard implementation is deployed by JavaSoft on Solaris, Windows and LINUX.
Default Garbage Collection Algorithms
Scavenge Garbage Collection
Scavenge Garbage Collection (also known as a Minor Collection) occurs when the Eden Space is full. By default, it is single-threaded but does not interrupt the other threads working on objects. It can be parallelized starting at Java 1.4 but if too more ParallelGCThreads are specified than CPU cores where the JVM is running, this can cause bottlenecks. For this reason, it is suggested to be careful in when and where to use the parallel options. These will be discussed further on.
Full Garbage Collection
A Full Garbage Collection (FullGC) occurs under these conditions:
The Java application explicitly calls System.gc(). This can be avoided by implementing the -
XX:+DisableExplicitGC parameter in the startup command for all Application Server JVMs (Tomcat,Application Server JVM, etc.)