A BRIEF INTRODUCTION TO Out Of Memory (OOM) :
Most of the Java developers across the Computing fraternity has come across the perils of running into a OOM (Out Of Memory Exception) . At times increasing the heap space isn’t enough to fix the issue. The JVM just doesn’t seem to recover from its perpetual memory saturation (or loss). Shown below are how a freaky OOM exception would look like:
JVM MEMORY MANAGEMENT:
JVM consists of three major memory chunks namely : Stack , Heap and Method Area.
1. HEAP - There is only one heap inside the JVM, and all threads share it. The heap contains nothing but objects.Arrays reside on the heap, including arrays of primitive types, but in Java, arrays are objects too. Heap space comprises of Eden Space, Survivor spaces and Old Generation.
You can explicitly state how big you want the Eden space using the –Xmn.
2. STACK - Inside the Java virtual machine, each thread is awarded a Java stack, which contains data no other thread can access, including the local variables, parameters, and return values of each method the thread has invoked.The data on the stack is limited to primitive types and object references.In the JVM, it is not possible to place the image of an actual object on the stack. All objects reside on the heap.
A frame is used to store data and partial results, as well as to perform dynamic linking, return values for methods, and dispatch exceptions.
A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes,whether that completion is normal or abrupt (it throws an uncaught exception). Frames are allocated from the Java virtual machine stack of the thread creating the frame. Each frame has its own array of local variables, its own operand stack, and a reference to the runtime constant pool of the class of the current method.
The sizes of the local variable array and the operand stack are determined at compile time and are supplied along with the code for the method associated with the frame. Thus the size of the frame data structure depends only on the implementation of the Java virtual machine, and the memory for these structures can be allocated simultaneously on method invocation.
Only one frame, the frame for the executing method, is active at any point in a given thread of control. This frame is referred to as the current frame, and its method is known as the current method. The class in which the current method is defined is the current class. Operations on local variables and the operand stack are typically with reference to the current frame.
Each thread in the jvm gets space allocated to it for keeping track of its stack frames. This memory is taken from the JVM’s native Stack space. In linux, the ulimit with a -s option controls native stack size. Naturally, the more threads you have, the more native stack space is consumed.If there’s not enough space to allocate another thread, you get an OOM that looks like this:
You can limit the size of each thread’s stack frame with the –Xss
3. METHOD AREA - The Java virtual machine has a method area that is shared among all Java virtual machine threads. The method area is analogous to the storage area for compiled code of a conventional language or analogous to the "text" segment in a UNIX process. It stores per-class structures such as the runtime constant pool, field and method data, and the code for methods and constructors, including the special methods (§3.9) used in class and instance initialization and interface type initialization.
The method area is created on virtual machine start-up. Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it. This version of the Java virtual machine specification does not mandate the location of the method area or the policies used to manage compiled code. The method area may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger method area becomes unnecessary. The memory for the method area does not need to be contiguous.
TYPES OF Out Of Memory (OOM) :
1. Permanent Generation Exhaustion Exceptions (Sun JVMs) :
The Sun JVM utilizes a generational model for object allocation. The permanent generation is used by the Sun JVM to store objects that are long lived, and to house certain internal JVM cache structures, such as the interned string cache. One of the object types that is stored in the permanent generation is java.lang.Class.
Because Process Commander generates Java classes for most rule types, it is important to size the permanent generation appropriately for the number of class objects that will be loaded by the application. If the amount of space in the permanent generation is inadequate for the number of class objects that are needed, an OutOfMemory exception is thrown, even if there is still plenty of space available in the new and tenured generation areas.A permanent generation exhaustion has a special OutOfMemory exception message:
Heap Dump files might be used to analyze such outages.
2. Native OutOfMemory Exceptions (Primarily IBM JVMs):
Native OutOfMemory exceptions have a special signature, and are sometimes accompanied by JVM process termination and the creation of an operating system core file (on UNIX/Linux platforms). The OutOfMemory stack shows Native Method as the highest class in the OutOfMemory exception stack, and this confirms that the exception originated from code running in native memory. Here is an example of a native OutOfMemory exception.
Native OutOfMemory exceptions occur when the JVM process has exhausted the memory areas dedicated to native operations. Native operations include all JNI (Java Native Interface) calls, zip inflation and deflation (for BLOBs), JIT (Just In-Time) method compilation, and any third-party shared library operations. All 32-bit JVM processes are restricted to a 4 GB maximum memory allocation because of the number of addressable memory spaces with 32 bits.
Both the JVM heap and native memory space must fit into 4 GBs. Generally, the more memory allocated to the main JVM heap for java object allocation, the less that is available for native operations. For example, if you allocate 3 GB of space to the JVM heap, there is only 1 GB of memory of space
left for native operations.
3. “Standard” OutOfMemory Exceptions:
Essentially all other OutOfMemory exceptions are “standard.” There is no special message inside or with the OutOfMemory exception stack, and the offending code is not a native method. Standard OutOfMemory exceptions themselves can be broken down into sub-categories through detailed inspection of the verbose GC log file, and analysis of the user load on the system either through conversation with the customer or measurement with SMA and other tools.
4. Memory Usage Spike: Analyze GC Verbose log.
Memory spikes are the most frequent cause of OutOfMemory exceptions. A memory spike involves a requestor (user or agent) requesting a large amount of memory space for objects. This could be based on a large database list, or on the creation of a very large HTML stream.
To determine if there has been a memory usage spike on the system, use the GC viewer of your choice for your JVM to graph the verbose GC log file in order to view total memory and free memory after each GC cycle over time. If the memory usage has an obvious spike preceding the OutOfMemory exception, you have found the type of problem similar to what the customer is experiencing.
Sometimes an OutOfMemory exception can occur with a usage spike when there is memory (even significant memory) still available in the heap. This can occur in IBM JVMs when there is significant memory fragmentation, which occurs when there are many small to medium-sized objects allocated over the whole JVM heap, and there isn’t enough contiguous space available for a single large memory request.
5. Memory Leaks: Analyze Heap Dump.
Memory leaks are the second most typical cause of standard OutOfMemory exceptions. A memory leak can be identified by graphing the verbose GC output. If it shows a linear or accelerating memory growth leading up to the exception, then the system is leaking memory somehow.
Fortunately the JVM vendors have already found and resolved many memory leaks, and the first step is to check whether the you have applied fixes to your system for known problems. If not, apply any unimplemented fixes and reevaluate. If your JVM has all the current fixes applied, then a heap dump analysis is required to determine the source of the leak. Heap dumps can be created on both Sun and IBM JVMs, although the methods differ somewhat.
TYPES OF TRACES AND DUMPS:
1. HEAP DUMPS:
The heap dump is a dump of all the live objects and classes.Ideally .PHD files for IBM JVM and .hprof,etc for SUN JVM.
HEAP DUMPS GENERATION TOOLS:
1. JHprof (Heap Profiler - Inbuilt with SUN JDK 1.6):
HPROF is capable of presenting CPU usage, heap allocation statistics and monitor contention profiles.In addition it can also report complete heap dumps and states of all the monitors and threads in the Java virtual machine. In terms of diagnosing problems, HPROF is useful when analyzing performance, lock contention, memory leaks, and other issues.
2. Ha34.jar (IBM Java Heap Dump Analyzer):
IBM Java Heap dump can be generated in either of two ways:
1. Explicit generation: When the Java heap is exhausted, Java Virtual Machine triggered generation is
enabled by default.
2. Java Virtual Machine triggered generation
To enable signal-based Java Heap dumps, the IBM_HEAPDUMP=TRUE environmental variable or the appropriate /JAVA_DUMP_OPTS must be set.
IBM Java Heap dump can be explicitly generated in either of the following ways:
1. By sending a signal to the JVM from the operating system
2. By using the HeapDump() method inside Java code that is being executed
3. For Linux and AIX, send the JVM the signal SIGQUIT (kill -3, or CTRL+\ in the console window).
4. For Windows, generate a SIGINT (press the Ctrl+Break keys Simultaneously).
The following events automatically trigger the JVM to produce a Java Heap dump:
1. A fatal native exception occurs in the JVM (not a Java Exception)
2. An OutOfMemoryError or heap exhaustion condition occurs (optional)
3. If Java Heap dumps are enabled, they are normally produced immediately before a thread dump. They are produced also if the JVM terminates unexpectedly (a crash).
3.JMap (Inbuilt with SUN JDK 1.6):
Prints shared objects memory maps or heap memory details of a given process or core file or a remote debug srever.
Prints the binary heap dump or Java core dump.
The -histo option can be used to obtain a class-wise histogram of the heap. For each class, it print the number of objects, memory size in bytes, and fully qualified class name. Note that internal classes in the HotSpot VM are prefixed with an “*”. The histogram is useful when trying to understand how the heap is used.
HEAP DUMPS ANALYSIS TOOLS:
1.Jhat(Inbuilt with SUN JDK 1.6):
The jhat tool provides a convenient means to browse the object topology in a heap snapshot.The tool parses a heap dump in binary format.This utility can help debug unintentional object retention. This term is used to describe an object that is no longer needed but is kept alive due to references through some path from the rootset. This can happen, for example, if an unintentional static reference to an object remains after the object is no longer needed, if an Observer or Listener fails to de-register itself from its subject when it is no longer needed, or if a Thread that refers to an object does not terminate when it should. Unintentional object retention is the Java language equivalent of a memory leak.The tool provides a number of standard queries. For example, the Roots query displays all reference paths from the rootset to a specified object and is particularly useful for finding unnecessary object retention.
In addition to the standard queries, you can develop your own custom queries with the Object Query Language (OQL) interface.When you issue the jhat command, the utility starts an HTTP server on a specified TCP port. You can then use any browser to connect to the server and execute queries on the specified heap dump.
2. ha34.jar (IBM Heap Analyser for IBM JVM 4.1):Used to analyze IBM .PHD files.
IBM HeapAnalyzer allows the finding of a possible Java heap leak area through its heuristic search engine and analysis of the Java heap dump in Java applications
Download the "ha34.jar" from IBM Alphaworks as shown below and Import the PHD files:
Import the PHD files.
JAVA THREAD DUMPS ANALYSIS TOOLS:
1. jca31.jar (IBM Thread Dump Analyser for IBM JVM 4.1):
Put the jar under jdk/bin
Import Thread Dump or Core Dump file and monitor.(Files like : javacore.20090205.092742.25866.txt)
3. JAVA CORE DUMPS:
During the run time of a Java™ process, some Java Virtual Machiness (JVMs) may not respond predictably and oftentimes seem to hang up for a long time or until JVM shutdown occurs. It is not easy to determine the root cause of these sorts of problems.
By triggering a javacore when a Java process does not respond, it is possible to collect diagnostic information related to the JVM and a Java application captured at a particular point during execution. For example, the information can be about the operating system, the application environment, threads, native stack, locks, and memory. The exact contents are dependent on the platform on which the application is running.
On some platforms, and in some cases, javacore is known as "javadump." The code that creates javacore is part of the JVM. One can control it by using environment variables and run-time switches. By default, a javacore occurs when the JVM terminates unexpectedly. A javacore can also be triggered by sending specific signals to the JVM. Although javacore or javadump is present in Sun Solaris JVMs, much of the content of the javacore is added by IBM and, therefore, is present only in IBM JVMs.
IBM Thread and Monitor Dump Analyzer for Java analyzes javacore and diagnoses monitor locks and thread activities in order to identify the root cause of hangs, deadlocks, and resource contention or monitor bottlenecks.
JAVA CORE DUMPS ANALYSIS TOOLS:
1. jca39.jar :
Copy the JAR into JDK bin and run as follows :
D:\SOHAM\HOME\CoreDumps\javacore.20090828.013414.30561.txt
Traverse to C:\Program Files\Java\jdk1.6.0\bin.
The summary:
Most of the Java developers across the Computing fraternity has come across the perils of running into a OOM (Out Of Memory Exception) . At times increasing the heap space isn’t enough to fix the issue. The JVM just doesn’t seem to recover from its perpetual memory saturation (or loss). Shown below are how a freaky OOM exception would look like:
java.lang.RuntimeException: java.lang.OutOfMemoryError at org.rl337.memtest.Main.allocateTenKilobytes(Main.java:25) at org.rl337.memtest.Main.doJavaHeapOOM(Main.java:33) at org.rl337.memtest.Main.run(Main.java:39) at org.rl337.memtest.Main.main(Main.java:44)
Exception in thread XXXX java.lang.OutOfMemoryError: PermGen space
java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start(Native Method) at org.rl337.memtest.Main.doJavaThreadOOM(Main.java:56) at org.rl337.memtest.Main.run(Main.java:64) at org.rl337.memtest.Main.main(Main.java:69)
JVM MEMORY MANAGEMENT:
JVM consists of three major memory chunks namely : Stack , Heap and Method Area.
1. HEAP - There is only one heap inside the JVM, and all threads share it. The heap contains nothing but objects.Arrays reside on the heap, including arrays of primitive types, but in Java, arrays are objects too. Heap space comprises of Eden Space, Survivor spaces and Old Generation.
- Eden space and Survivor space (The Young generation): Eden space is where all memory allocations take place. As eden space is filled up, two things happen. First, all objects in eden space get garbage collected.Those objects that survive the garbage collection get moved into one of two “survivor” spaces. If eden space is never exhausted, objects can also be moved into a survivor space by “living long enough”. Collectively, the Eden space and the survivor spaces are referred to as the “Young Generation” or “New Generation”. By default, the young generation doesn’t take up much space in the jvm and is garbage collected fairly often.
- Old Generation or the Tenured Generation: When objects spend enough time in survivor space, or if forced to because of an overflowing eden space, they get promoted to what amounts to the balance of the java managed heap. (I’ll get to permanent generation in a bit). This memory is called the “Old Generation” or the “Tenured Generation”. When the old generation space is full, a “Full Garbage Collection” occurs. These are far more expensive than young generation GC simply because the sheer volume of memory checked is larger.
- Permanent generation: Finally there’s the Permanent generation space. This area is used for classes that get loaded. I also noticed activity in this space as the “Just In Time” compiler recompiles classes into “native” code. This space IS controlled by java, but it is NOT part of the java “heap” which is comprised of the new and old generation spaces.
java -Xms20m -Xmx30m <class_name>
2. STACK - Inside the Java virtual machine, each thread is awarded a Java stack, which contains data no other thread can access, including the local variables, parameters, and return values of each method the thread has invoked.The data on the stack is limited to primitive types and object references.In the JVM, it is not possible to place the image of an actual object on the stack. All objects reside on the heap.
A frame is used to store data and partial results, as well as to perform dynamic linking, return values for methods, and dispatch exceptions.
A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes,whether that completion is normal or abrupt (it throws an uncaught exception). Frames are allocated from the Java virtual machine stack of the thread creating the frame. Each frame has its own array of local variables, its own operand stack, and a reference to the runtime constant pool of the class of the current method.
The sizes of the local variable array and the operand stack are determined at compile time and are supplied along with the code for the method associated with the frame. Thus the size of the frame data structure depends only on the implementation of the Java virtual machine, and the memory for these structures can be allocated simultaneously on method invocation.
Only one frame, the frame for the executing method, is active at any point in a given thread of control. This frame is referred to as the current frame, and its method is known as the current method. The class in which the current method is defined is the current class. Operations on local variables and the operand stack are typically with reference to the current frame.
Each thread in the jvm gets space allocated to it for keeping track of its stack frames. This memory is taken from the JVM’s native Stack space. In linux, the ulimit with a -s option controls native stack size. Naturally, the more threads you have, the more native stack space is consumed.If there’s not enough space to allocate another thread, you get an OOM that looks like this:
java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start(Native Method) at org.rl337.memtest.Main.doJavaThreadOOM(Main.java:56) at org.rl337.memtest.Main.run(Main.java:64) at org.rl337.memtest.Main.main(Main.java:69)
3. METHOD AREA - The Java virtual machine has a method area that is shared among all Java virtual machine threads. The method area is analogous to the storage area for compiled code of a conventional language or analogous to the "text" segment in a UNIX process. It stores per-class structures such as the runtime constant pool, field and method data, and the code for methods and constructors, including the special methods (§3.9) used in class and instance initialization and interface type initialization.
The method area is created on virtual machine start-up. Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it. This version of the Java virtual machine specification does not mandate the location of the method area or the policies used to manage compiled code. The method area may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger method area becomes unnecessary. The memory for the method area does not need to be contiguous.
TYPES OF Out Of Memory (OOM) :
1. Permanent Generation Exhaustion Exceptions (Sun JVMs) :
The Sun JVM utilizes a generational model for object allocation. The permanent generation is used by the Sun JVM to store objects that are long lived, and to house certain internal JVM cache structures, such as the interned string cache. One of the object types that is stored in the permanent generation is java.lang.Class.
Because Process Commander generates Java classes for most rule types, it is important to size the permanent generation appropriately for the number of class objects that will be loaded by the application. If the amount of space in the permanent generation is inadequate for the number of class objects that are needed, an OutOfMemory exception is thrown, even if there is still plenty of space available in the new and tenured generation areas.A permanent generation exhaustion has a special OutOfMemory exception message:
java.lang.OutOfMemoryError: PermGen space
2. Native OutOfMemory Exceptions (Primarily IBM JVMs):
Native OutOfMemory exceptions have a special signature, and are sometimes accompanied by JVM process termination and the creation of an operating system core file (on UNIX/Linux platforms). The OutOfMemory stack shows Native Method as the highest class in the OutOfMemory exception stack, and this confirms that the exception originated from code running in native memory. Here is an example of a native OutOfMemory exception.
Native OutOfMemory exceptions occur when the JVM process has exhausted the memory areas dedicated to native operations. Native operations include all JNI (Java Native Interface) calls, zip inflation and deflation (for BLOBs), JIT (Just In-Time) method compilation, and any third-party shared library operations. All 32-bit JVM processes are restricted to a 4 GB maximum memory allocation because of the number of addressable memory spaces with 32 bits.
Both the JVM heap and native memory space must fit into 4 GBs. Generally, the more memory allocated to the main JVM heap for java object allocation, the less that is available for native operations. For example, if you allocate 3 GB of space to the JVM heap, there is only 1 GB of memory of space
left for native operations.
3. “Standard” OutOfMemory Exceptions:
Essentially all other OutOfMemory exceptions are “standard.” There is no special message inside or with the OutOfMemory exception stack, and the offending code is not a native method. Standard OutOfMemory exceptions themselves can be broken down into sub-categories through detailed inspection of the verbose GC log file, and analysis of the user load on the system either through conversation with the customer or measurement with SMA and other tools.
4. Memory Usage Spike: Analyze GC Verbose log.
Memory spikes are the most frequent cause of OutOfMemory exceptions. A memory spike involves a requestor (user or agent) requesting a large amount of memory space for objects. This could be based on a large database list, or on the creation of a very large HTML stream.
To determine if there has been a memory usage spike on the system, use the GC viewer of your choice for your JVM to graph the verbose GC log file in order to view total memory and free memory after each GC cycle over time. If the memory usage has an obvious spike preceding the OutOfMemory exception, you have found the type of problem similar to what the customer is experiencing.
Sometimes an OutOfMemory exception can occur with a usage spike when there is memory (even significant memory) still available in the heap. This can occur in IBM JVMs when there is significant memory fragmentation, which occurs when there are many small to medium-sized objects allocated over the whole JVM heap, and there isn’t enough contiguous space available for a single large memory request.
5. Memory Leaks: Analyze Heap Dump.
Memory leaks are the second most typical cause of standard OutOfMemory exceptions. A memory leak can be identified by graphing the verbose GC output. If it shows a linear or accelerating memory growth leading up to the exception, then the system is leaking memory somehow.
Fortunately the JVM vendors have already found and resolved many memory leaks, and the first step is to check whether the you have applied fixes to your system for known problems. If not, apply any unimplemented fixes and reevaluate. If your JVM has all the current fixes applied, then a heap dump analysis is required to determine the source of the leak. Heap dumps can be created on both Sun and IBM JVMs, although the methods differ somewhat.
TYPES OF TRACES AND DUMPS:
1. HEAP DUMPS:
The heap dump is a dump of all the live objects and classes.Ideally .PHD files for IBM JVM and .hprof,etc for SUN JVM.
HEAP DUMPS GENERATION TOOLS:
1. JHprof (Heap Profiler - Inbuilt with SUN JDK 1.6):
HPROF is capable of presenting CPU usage, heap allocation statistics and monitor contention profiles.In addition it can also report complete heap dumps and states of all the monitors and threads in the Java virtual machine. In terms of diagnosing problems, HPROF is useful when analyzing performance, lock contention, memory leaks, and other issues.
It can be found in the $JAVA_HOME/demo/jvmti/hprof directory (where $JAVA_HOME indicates the directory where the JDK is installed). -Class Profiling: java -agentlib:hprof <ToBeProfiledClass> -For help: java -agentlib:hprof=help -A profile is generated when Ctrl-\ or Ctrl-Break (depending on platform) is pressed. -For heap sites: java -agentlib:hprof=heap=sites soham -For heap dump: java -agentlib:hprof=heap=dump soham
2. Ha34.jar (IBM Java Heap Dump Analyzer):
IBM Java Heap dump can be generated in either of two ways:
1. Explicit generation: When the Java heap is exhausted, Java Virtual Machine triggered generation is
enabled by default.
2. Java Virtual Machine triggered generation
To enable signal-based Java Heap dumps, the IBM_HEAPDUMP=TRUE environmental variable or the appropriate /JAVA_DUMP_OPTS must be set.
IBM Java Heap dump can be explicitly generated in either of the following ways:
1. By sending a signal to the JVM from the operating system
2. By using the HeapDump() method inside Java code that is being executed
3. For Linux and AIX, send the JVM the signal SIGQUIT (kill -3, or CTRL+\ in the console window).
4. For Windows, generate a SIGINT (press the Ctrl+Break keys Simultaneously).
The following events automatically trigger the JVM to produce a Java Heap dump:
1. A fatal native exception occurs in the JVM (not a Java Exception)
2. An OutOfMemoryError or heap exhaustion condition occurs (optional)
3. If Java Heap dumps are enabled, they are normally produced immediately before a thread dump. They are produced also if the JVM terminates unexpectedly (a crash).
3.JMap (Inbuilt with SUN JDK 1.6):
Prints shared objects memory maps or heap memory details of a given process or core file or a remote debug srever.
C:\Program Files\Java\jdk1.6.0\bin>jmap -dump:format=b:file=heap1.bin <PID>
C:\Program Files\Java\jdk1.6.0\bin>jmap -histo <PID>
HEAP DUMPS ANALYSIS TOOLS:
1.Jhat(Inbuilt with SUN JDK 1.6):
The jhat tool provides a convenient means to browse the object topology in a heap snapshot.The tool parses a heap dump in binary format.This utility can help debug unintentional object retention. This term is used to describe an object that is no longer needed but is kept alive due to references through some path from the rootset. This can happen, for example, if an unintentional static reference to an object remains after the object is no longer needed, if an Observer or Listener fails to de-register itself from its subject when it is no longer needed, or if a Thread that refers to an object does not terminate when it should. Unintentional object retention is the Java language equivalent of a memory leak.The tool provides a number of standard queries. For example, the Roots query displays all reference paths from the rootset to a specified object and is particularly useful for finding unnecessary object retention.
In addition to the standard queries, you can develop your own custom queries with the Object Query Language (OQL) interface.When you issue the jhat command, the utility starts an HTTP server on a specified TCP port. You can then use any browser to connect to the server and execute queries on the specified heap dump.
-Generate the binary heap file using JMap,say "heap1.bin" -Run the jhat application. -C:\Program Files\Java\jdk1.6.0\bin>jhat heap1.bin -the utility starts an HTTP server on a specified TCP port 7000. -Goto IE :http://localhost:7000
2. ha34.jar (IBM Heap Analyser for IBM JVM 4.1):Used to analyze IBM .PHD files.
IBM HeapAnalyzer allows the finding of a possible Java heap leak area through its heuristic search engine and analysis of the Java heap dump in Java applications
Download the "ha34.jar" from IBM Alphaworks as shown below and Import the PHD files:
C:\Program Files\Java\jdk1.6.0\bin>java -Xms10m -Xmx12m -jar ha34.jar
In tree view, you can see detailed information of a node, you can search for total size drop between parent and child or you can find an address by selecting a node and click on right mouse button.
- If you want to review detailed information regarding a node, select the following menu.
2. STACK TRACE OR THREAD DUMP:
JAVA THREAD DUMP OR STACK TRACE GENERATING TOOLS:
1. JStack:(Inbuilt with SUN JDK 1.6):
The utility attaches to the specified process (or core file) and prints the stack traces of all threads that are attached to the virtual machine (this includes Java threads and VM internal threads).
-C:\Program Files\Java\jdk1.6.0\bin>jstack -l 3768 (-l represents long trace prints)
JAVA THREAD DUMPS ANALYSIS TOOLS:
1. jca31.jar (IBM Thread Dump Analyser for IBM JVM 4.1):
Put the jar under jdk/bin
C:\Program Files\Java\jdk1.6.0\bin>java -Xmx500m -jar jca31.jar
3. JAVA CORE DUMPS:
During the run time of a Java™ process, some Java Virtual Machiness (JVMs) may not respond predictably and oftentimes seem to hang up for a long time or until JVM shutdown occurs. It is not easy to determine the root cause of these sorts of problems.
By triggering a javacore when a Java process does not respond, it is possible to collect diagnostic information related to the JVM and a Java application captured at a particular point during execution. For example, the information can be about the operating system, the application environment, threads, native stack, locks, and memory. The exact contents are dependent on the platform on which the application is running.
On some platforms, and in some cases, javacore is known as "javadump." The code that creates javacore is part of the JVM. One can control it by using environment variables and run-time switches. By default, a javacore occurs when the JVM terminates unexpectedly. A javacore can also be triggered by sending specific signals to the JVM. Although javacore or javadump is present in Sun Solaris JVMs, much of the content of the javacore is added by IBM and, therefore, is present only in IBM JVMs.
IBM Thread and Monitor Dump Analyzer for Java analyzes javacore and diagnoses monitor locks and thread activities in order to identify the root cause of hangs, deadlocks, and resource contention or monitor bottlenecks.
JAVA CORE DUMPS ANALYSIS TOOLS:
1. jca39.jar :
Copy the JAR into JDK bin and run as follows :
C:\INSTALLATIONS\JAVA\JAVA5\Java 1.5\jdk1.5.0_02\bin>java -Xmx200m -jar jca39.jar
D:\SOHAM\HOME\CoreDumps\javacore.20090828.013414.30561.txt
MONITORING APPLICATIONS FOR POSSIBLE Out Of Memory (OOM):
JConsole (Inbuilt with SUN JDK 1.6): Track Heap, Eden, Survivor, Permanent Generation Spaces
Java Monitoring and Management Console (JConsole) tool. It uses the extensive instrumentation of the Java virtual machine to provide information on performance and resource consumption of applications running on the Java platform using Java Management Extension (JMX) technology. It not only defines the management interfaces for the Java virtual machine, but also provides out-of-the-box remote monitoring and management on the Java platform and of applications that run on it.
-Install JDK 1.6. -Set "path","JAVA_HOME" amd "JRE_HOME". -Start Tomcat 5.5 from cmd.(Or any other application that uses the above set JDK configurations) -Find the process ID (PID) from the Task Manager.(say 2468) for the "java.exe" or "javaw.exe".
C:\Program Files\Java\jdk1.6.0\bin>jconsole 2468
Other Available Features: Monitor Heap,Eden,Survivor,etc
Perform forceful GC or take memory snap shots at chosen time intervals.
The summary:
Reading Materials And References :
http://www.artima.com/insidejvm/ed2/jvm13.html
http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf
Hi Soham,
ReplyDeleteNice blog! Is there an email address I can contact you in private?
You can contact me at : soham.roy@hotmail.com
ReplyDeleteThanks for this Wonderful One-Stop article that mentions not just the difference about JVM parameters, but also use different utilities to monitor whats going wrong.
ReplyDeleteI can finally get rid of all the different shortcuts that are specific to each kind of OOM error.