how to open heap dump phd file

• Books Get Your Hands Dirty on Clean Architecture Stratospheric
• Contribute Become an Author Writing Guide Author Workflow Author Payment
• Services Book me Advertise
• Categories Spring Boot Java Node Kotlin AWS Software Craft Simplify! Meta Book Reviews

Creating and Analyzing Java Heap Dumps

• March 1, 2021

As Java developers, we are familiar with our applications throwing OutOfMemoryErrors or our server monitoring tools throwing alerts and complaining about high JVM memory utilization.

To investigate memory problems, the JVM Heap Memory is often the first place to look at.

To see this in action, we will first trigger an OutOfMemoryError and then capture a heap dump. We will next analyze this heap dump to identify the potential objects which could be the cause of the memory leak.

Example Code

What is a heap dump.

Whenever we create a Java object by creating an instance of a class, it is always placed in an area known as the heap. Classes of the Java runtime are also created in this heap.

The heap gets created when the JVM starts up. It expands or shrinks during runtime to accommodate the objects created or destroyed in our application.

When the heap becomes full, the garbage collection process is run to collect the objects that are not referenced anymore (i.e. they are not used anymore). More information on memory management can be found in the Oracle docs .

Heap dumps contain a snapshot of all the live objects that are being used by a running Java application on the Java heap. We can obtain detailed information for each object instance, such as the address, type, class name, or size, and whether the instance has references to other objects.

Heap dumps have two formats:

• the classic format, and
• the Portable Heap Dump (PHD) format.

PHD is the default format. The classic format is human-readable since it is in ASCII text, but the PHD format is binary and should be processed by appropriate tools for analysis.

Sample Program to Generate an OutOfMemoryError

To explain the analysis of a heap dump, we will use a simple Java program to generate an OutOfMemoryError :

We keep on allocating the memory by running a for loop until a point is reached, when JVM does not have enough memory to allocate, resulting in an OutOfMemoryError being thrown.

Finding the Root Cause of an OutOfMemoryError

We will now find the cause of this error by doing a heap dump analysis. This is done in two steps:

• Capture the heap dump
• Analyze the heap dump file to locate the suspected reason.

We can capture heap dump in multiple ways. Let us capture the heap dump for our example first with jmap and then by passing a VM argument in the command line.

Generating a Heap Dump on Demand with jmap

jmap is packaged with the JDK and extracts a heap dump to a specified file location.

To generate a heap dump with jmap , we first find the process ID of our running Java program with the jps tool to list down all the running Java processes on our machine:

Next, we run the jmap command to generate the heap dump file:

After running this command the heap dump file with extension hprof is created.

The option live is used to collect only the live objects that still have a reference in the running code. With the live option, a full GC is triggered to sweep away unreachable objects and then dump only the live objects.

Automatically Generating a Heap Dump on OutOfMemoryError s

This option is used to capture a heap dump at the point in time when an OutOfMemoryError occurred. This helps to diagnose the problem because we can see what objects were sitting in memory and what percentage of memory they were occupying right at the time of the OutOfMemoryError .

We will use this option for our example since it will give us more insight into the cause of the crash.

Let us run the program with the VM option HeapDumpOnOutOfMemoryError from the command line or our favorite IDE to generate the heap dump file:

After running our Java program with these VM arguments, we get this output:

As we can see from the output, the heap dump file with the name: hdump.hprof is created when the OutOfMemoryError occurs.

Other Methods of Generating Heap Dumps

Some of the other methods of generating a heap dump are:

jcmd : jcmd is used to send diagnostic command requests to the JVM. It is packaged as part of the JDK. It can be found in the \bin folder of a Java installation.

JVisualVM : Usually, analyzing heap dump takes more memory than the actual heap dump size. This could be problematic if we are trying to analyze a heap dump from a large server on a development machine. JVisualVM provides a live sampling of the Heap memory so it does not eat up the whole memory.

Analyzing the Heap Dump

What we are looking for in a Heap dump is:

• Objects with high memory usage
• Object graph to identify objects of not releasing memory
• Reachable and unreachable objects

Eclipse Memory Analyzer (MAT) is one of the best tools to analyze Java heap dumps. Let us understand the basic concepts of Java heap dump analysis with MAT by analyzing the heap dump file we generated earlier.

We will first start the Memory Analyzer Tool and open the heap dump file. In Eclipse MAT, two types of object sizes are reported:

• Shallow heap size : The shallow heap of an object is its size in the memory
• Retained heap size : Retained heap is the amount of memory that will be freed when an object is garbage collected.

Overview Section in MAT

After opening the heap dump, we will see an overview of the application’s memory usage. The piechart shows the biggest objects by retained size in the overview tab as shown here:

For our application, this information in the overview means if we could dispose of a particular instance of java.lang.Thread we will save 1.7 GB, and almost all of the memory used in this application.

Histogram View

While that might look promising, java.lang.Thread is unlikely to be the real problem here. To get a better insight into what objects currently exist, we will use the Histogram view:

We have filtered the histogram with a regular expression “io.pratik.* " to show only the classes that match the pattern. With this view, we can see the number of live objects: for example, 243 BrandedProduct objects, and 309 Price Objects are alive in the system. We can also see the amount of memory each object is using.

There are two calculations, Shallow Heap and Retained Heap. A shallow heap is the amount of memory consumed by one object. An Object requires 32 (or 64 bits, depending on the architecture) for each reference. Primitives such as integers and longs require 4 or 8 bytes, etc… While this can be interesting, the more useful metric is the Retained Heap.

Retained Heap Size

The retained heap size is computed by adding the size of all the objects in the retained set. A retained set of X is the set of objects which would be removed by the Garbage Collector when X is collected.

The retained heap can be calculated in two different ways, using the quick approximation or the precise retained size:

By calculating the Retained Heap we can now see that io.pratik.ProductGroup is holding the majority of the memory, even though it is only 32 bytes (shallow heap size) by itself. By finding a way to free up this object, we can certainly get our memory problem under control.

Dominator Tree

The dominator tree is used to identify the retained heap. It is produced by the complex object graph generated at runtime and helps to identify the largest memory graphs. An Object X is said to dominate an Object Y if every path from the Root to Y must pass through X.

Looking at the dominator tree for our example, we can see which objects are retained in the memory.

We can see that the ProductGroup object holds the memory instead of the Thread object. We can probably fix the memory problem by releasing objects contained in this object.

Leak Suspects Report

We can also generate a “Leak Suspects Report” to find a suspected big object or set of objects. This report presents the findings on an HTML page and is also saved in a zip file next to the heap dump file.

Due to its smaller size, it is preferable to share the “Leak Suspects Report” report with teams specialized in performing analysis tasks instead of the raw heap dump file.

The report has a pie chart, which gives the size of the suspected objects:

For our example, we have one suspect labeled as “Problem Suspect 1” which is further described with a short description:

Apart from the summary, this report also contains detailed information about the suspects which is accessed by following the “details” link at the bottom of the report:

The detailed information is comprised of :

Shortest paths from GC root to the accumulation point : Here we can see all the classes and fields through which the reference chain is going, which gives a good understanding of how the objects are held. In this report, we can see the reference chain going from the Thread to the ProductGroup object.

Accumulated Objects in Dominator Tree : This gives some information about the content which is accumulated which is a collection of GroceryProduct objects here.

In this post, we introduced the heap dump, which is a snapshot of a Java application’s object memory graph at runtime. To illustrate, we captured the heap dump from a program that threw an OutOfMemoryError at runtime.

We then looked at some of the basic concepts of heap dump analysis with Eclipse Memory Analyzer: large objects, GC roots, shallow vs. retained heap, and dominator tree, all of which together will help us to identify the root cause of specific memory issues.

Software Engineer, Consultant and Architect with current expertise in Enterprise and Cloud Architecture, serverless technologies, Microservices, and Devops.

Recent Posts

• Spring Boot

Using Amazon S3 with Spring Cloud AWS

• May 27, 2024

In modern web applications, storing and retrieving files has become a common requirement. Whether it is user uploaded content like images and documents or application generated logs and reports, having a reliable and scalable storage solution is crucial.

Inheritance, Polymorphism, and Encapsulation in Kotlin

• Ezra Kanake
• May 12, 2024

In the realm of object-oriented programming (OOP), Kotlin stands out as an expressive language that seamlessly integrates modern features with a concise syntax.

Publisher-Subscriber Pattern Using AWS SNS and SQS in Spring Boot

• May 3, 2024

In an event-driven architecture where multiple microservices need to communicate with each other, the publisher-subscriber pattern provides an asynchronous communication model to achieve this.

How to Capture and Analyze Java Heap Dump

• Java Howtos
• How to Capture and Analyze Java Heap …

Introduction to Heap Dump and Its Formats

Example code causing outofmemoryerror in java, different ways to capture heap dump, analyze java heap dump.

Heap dumps contain a snapshot of all live objects the running Java application uses on a Java heap. This tutorial educates about heap dump, its various formats, and its importance.

Further, we will go through an example demonstrating OutOfMemoryError , which will lead to various approaches to capture heap dump and a tool to analyze it.

A heap contains all the objects that we create by instantiating a class. Every class of Java runtime is also created in this heap.

This heap is created when JVM (Java Virtual Machine) starts and can expand/shrink during runtime to adjust objects destroyed or created in an application.

The garbage collection process runs whenever a heap gets full, this process collects all the objects that are no longer used, or we can say not referenced anymore (you can find more on memory manage here . Usually, heap dumps are stored in the binary format hprof files.

We can retrieve detailed information about each object instance like type, class name, address, size and whether an instance contains references to another object(s) or not. The heap dumps can be in one of the following two formats:

• The Portable Heap Dump Format (also known as PHD format)
• The Classic Format

Remember that the portable heap dump is the default format and is in binary which must be processed for further analysis. On the other hand, the classic format is in ASCII text which is human-readable.

You may read about these two formats here .

Importance of Using Heap Dump

Usually, we get the advantage of heap dump when an application is crashed due to OutOfMemoryError or a Java application consuming more memory than expected.

Heap dump helps us to identify the primary causes for the error and other details, for instance, the number of objects in every class, memory usage for every class, etc.

It also assists in capturing the memory size occupied by each Java object of an application. All this captured information can be useful for finding an actual code causing memory leak issues.

Let’s look at a code example causing OutOfMemoryError , which will lead to various ways to capture Java heap dump.

The above code will keep allocating memory by executing the while loop until a specific point is reached where Java Virtual Machine cannot allocate enough memory.

At that point, we will get java.lang.OutOfMemoryError: Java heap space error.

This is where we need to do heap dump analysis to find the reasons causing OutOfMemoryError . It can be done in two steps.

First, capture the heap dump and then analyze the heap dump file to find the suspected reasons.

There are multiple ways to capture heap dump. Let’s learn the following one by one below.

• Generate Heap Dump Automatically

Use jmap to Capture Heap Dump

The jmap tool prints memory statistics in a running Java Virtual Machine (JVM); we can also use it for remote and local processes.

We use the -dump option to capture heap dump using the jmap tool, which we can use from the bin folder of JDK’s home directory.

Following is a brief description of the options that we have specified above:

Note that we can use the jps command to get pid . Additionally, jmap was introduced as an experimental tool in JDK, and it is unsupported; therefore, in some situations, you may have to go for other tools instead of using jmap .

Use JVisualVM to Capture Heap Dump

The JVisualVM is a graphical user interface that allows us to keep track of profiling Java applications and troubleshooting. It is simple, easy to use and lets us capture a heap dump.

According to this , it was available with Oracle JDK 6, 7, and 8. As of JDK 9 or later, JVisualVM is no longer provided with Oracle JDK; the users have to download it separately if they want to use it.

Let’s download it from visualvm.github.io , extract the .zip file, locate visualvm.exe in the bin folder, double-click on it, hit the I Accept button when prompt, and you will see the following screen.

All the Java processes that are currently running will be listed under Local . We can capture a heap dump by selecting the desired Java process, right-clicking on it, and choosing the Heap Dump option.

It will open a new tab demonstrating all the necessary information.

Use jcmd to Capture Heap Dump

This tool can also be found in the bin folder of JDK’s home directory; in our case, it is C:\Program Files\Java\jdk-18\bin . Yours might be different if you have not installed Java on the default location.

The jcmd sends command requests to a Java Virtual Machine. Remember that we have to use it on the same machine running a Java process.

It has multiple commands, one of them is GC.heap-dump , which we will use to capture a heap dump by specifying the process id ( pid ) and a path for an output file. See the syntax of the jcmd command below.

Like jmap , it will also generate the dump in binary format.

Capture Heap Dump Automatically

All the approaches we have learned capture heap dump manually at a particular time, but in some circumstances, we have to generate heap dump as soon as java.lang.OutOfMemoryError occurs.

Here, automatically generating a heap dump will help us investigate an error.

Considering these scenarios, Java serves with HeapDumpOnOutOfMemoryError , a command line option that can generate a heap dump when an application throws java.lang.OutOfMemoryError .

By default, the above command will store the dump in the java_pid<pid>.hprof file located where our application is running. We can specify a custom directory or file and set it in a HeapDumpPath option.

Now, we can locate the created file containing heap dump in logs as follows whenever our application runs out of memory via this option.

We can see that the above text is written to the java_pid12876.hprof file, and there is no overhead while running our application using this option.

It is good to use this option for all applications, particularly in production, because you will never know when OutOfMemoryError will occur.

Remember that we can use this option at runtime using HotSpotDiagnostic MBean . For that, JConsole is used and set HeapDumpOnOutOfMemoryError VM option to true .

Use JMX to Capture Heap Dump

In this method, we will be using HotSpotDiagnostic MBean , which provides a dumpHeap method accepting the following two parameters:

We can invoke it in two ways to capture a heap dump, invoke it programmatically or use the JMX client like JConsole located in the bin folder of JDK’s home directory. We will be using JMX here, but you can learn how to invoke it programmatically here .

Using HotSpotDiagnostic MBean via the JMX client ( JConsole ) is the easiest way to open JConsole , connect to the running Java process, navigate to the MBeans tab, and look for HotSpotDiagnostic under com.sun.management .

We can find the dumpHeap method under the Operations dropdown, where we can specify outputFile and live parameters into p0 and p1 text fields to perform the dumpHeap operation as demonstrated below.

Now, it’s time to analyze the Java heap dump.

In Java heap dump, we need to look for objects using high memory , objects graph to find objects that are not releasing memory , and reachable & unreachable objects .

The Eclipse Memory Analyzer (MAT) is best for analyzing the Java heap dump that we generated earlier. We will start Memory Analyzer Tool and open a heap dump file to do that.

In Eclipse Memory Analyzer (MAT), we will have two kinds of object sizes that are briefly explained below.

• Shallow Heap Size - An object’s shallow heap is its size in memory.
• Retained Heap Size - It is an amount of memory that will be freed once an object is garbage collected.

Once the heap dump file is opened, we can see a summary of the memory usage of an application. Now, we can easily figure out what is causing OutOfMemoryError .

Mehvish Ashiq is a former Java Programmer and a Data Science enthusiast who leverages her expertise to help others to learn and grow by creating interesting, useful, and reader-friendly content in Computer Programming, Data Science, and Technology.

Related Article - Java Heap

• How to Increase Heap Space in Java
• How to Implement Min-Heap in Java
• How to Implement Min-Max Heap in Java

• Java Software
• Java SE Downloads
• Java SE 8 Documentation

Java VisualVM - Browsing a Heap Dump

You can use Java VisualVM to browse the contents of a heap dump file and quickly see the allocated objects in the heap. Heap dumps are displayed in the heap dump sub-tab in the main window. You can open binary format heap dump files ( .hprof ) saved on your local system or use Java VisualVM to take heap dumps of running applications.

A heap dump is a snapshot of all the objects in the Java Virtual Machine (JVM) heap at a certain point in time. The JVM software allocates memory for objects from the heap for all class instances and arrays. The garbage collector reclaims the heap memory when an object is no longer needed and there are no references to the object. By examining the heap you can locate where objects are created and find the references to those objects in the source. If the JVM software is failing to remove unneeded objects from the heap, Java VisualVM can help you locate the nearest garbage collecting root for the object.

Opening a Heap Dump File

If you have a heap dump file saved on your local system, you can open the file in Java VisualVM by choosing File > Load from the main menu. Java VisualVM can open heap dumps saved in the .hprof file format. When you open a saved heap dump, the heap dump opens as a tab in the main window.

Taking a Heap Dump

You can use Java VisualVM to take a heap dump of a local running application. When you use Java VisualVM to take a heap dump, the file is only temporary until you explicitly save it. If you do not save the file, the file will be deleted when the application terminates.

You can take a heap dump by doing either of the following:

• Right-click the application in the Applications window and choose Heap Dump.
• Click Heap Dump in the Monitor tab of the application.

Heap dumps for a local application open as sub-tabs in the application's tab. The heap dump also appears as a time-stamped heap dump node under the application node in the Applications window. To save a heap dump to your local system, right-click the heap dump in the Applications window and choose Save As.

Browsing a Heap Dump

Java VisualVM enables you to visually browse heap dumps in the following views:

Summary View

When you open a heap dump, Java VisualVM displays the Summary view by default. The Summary view displays the running environment where the heap dump was taken and other system properties.

Classes View

The Classes view displays a list of classes and the number and percentage of instances referenced by that class. You can view a list of the instances of a specific class by right-clicking the name and choosing Show in Instances View.

You can sort how results are displayed by clicking a column heading. You can use the filter below the list to filter the classes by name or limit the displayed results to sub-classes of a class by right-clicking a class name and choosing Show Only Subclasses.

Instances View

The Instance view displays object instances for a selected class. When you select an instance from the Instance pane, Java VisualVM displays the fields of that class and references to that class in the respective panes. In the References pane, you can right-click an item and choose Show Nearest GC Root to display the nearest garbage collection root object.

Heap dump analysis using Eclipse Memory Analyzer Tool (MAT)

A heap dump is a snapshot of all the Java objects that exist in the heap space. The heap dump file is usually stored with .hprof extension.

In this post, we will see how you can take the heap dump of your running Java application and use Eclipse’s Memory Analyzer (MAT) to identify memory hotspots and possibility detect memory leak.

Why and When should I take the Heap dump?

You may need to take the Heap dump if your Java application is taking up more memory than you expected or your Java application crashed with OutOfMemoryError. Analyzing the heap dump will lead us to the root cause of the anomaly.

Using the heap dump we can find details like the memory usage per class, number of objects per class, etc. We can also go into fine details and find out the amount of memory retained by a single Java object in the application. These details can help us pinpoint the actual code that is causing the memory leak issues.

How do you analyze very large Heap dumps?

Usually analyzing heap dump takes even more memory than the actual heap dump size and this may be problematic if you are trying to analyze heap dump from a large server on your development machine. For instance, a server may have crashed with a heap dump of size 24 GB and your local machine may only have 16 GB of memory. Therefore, tools like MAT, Jhat won’t be able to load the heap dump file. In this case, you should either analyze the heap dump on the same server machine which doesn’t have memory constraint or use live memory sampling tools provided by VisualVM.

How to take a Heap dump of your running Java Application

There are several ways to take a heap dump. We will talk about the 3 easiest ways to do it.

Command-line interface to generate the Heap Dump

These steps are common for all operating systems including Windows, Linux, and macOS.

• Find the process id of your running Java application. You can use the jps  tool to list down all the running Java processes on your local machine. The processes will be listed in the following format “<pid> <MainClass>”

The option live is important if you want to collect only the live objects i.e objects that still have a reference in the running code.

VisualVM to generate the Heap Dump

Visual VM makes it very easy to take a heap dump running on your local machine. The following steps can be used to generate heap dump using VisualVM

• Start Visual VM and connect your local Java Application to it.

• After clicking on the heap dump you will be redirected to a new tab from which you can find out the location of your heap dump.

JConsole to generate the Heap dump

• Connect your application to JConsole .
• Switch to MBeans tab and select com.sun.management > HotSpotDiagnostic > Operations > dumpHeap.

• The parameter p0 is the location and the name of the heap dump file. Ensure that you add the “.hprof” extension at the end of the file name.
• The parameter p1, if set to true, performs a GC before dumping the heap so that only live objects are present in the heap dump.

Which tools can be used to analyze the heap dump or open the .hprof file?

Once you have the heap dump the next step is to analyze it using a tool. There are multiple paid and equally good open source tools available to analyze the Heap dump. Memory Analyzer (MAT) is one of the best open-source tool that can be used as a plugin with Eclipse or as a standalone application if you don’t have Eclipse IDE installed. Apart from MAT, you can use Jhat, VisualVM. However, in this post, we will discuss the features provided with MAT.

Downloading the Memory Analyzer (MAT)

There are two ways to use the Memory Analyzer tool.

Integrating MAT plugin with Eclipse

• Open Eclipse IDE and select Help > Eclipse Marketplace.

• Restart Eclipse and the plugin is ready to be used.

Downloading the standalone version of Eclipse MAT

• Download and install the Java Development Kit .
• Download the install standalone MAT application from this link .

Loading Heap dump file in Eclipse MAT

We will be analyzing the heap dump generated by this Java application . The memory leak in the application is discussed in depth in this tutorial . And the screenshots posted below are from the MAT plugin used with Eclipse IDE.

The steps to load the heap dump are as follows.

• Open Eclipse IDE or the standalone MAT Tool.
• From the toolbar, Select Files > Open File from the dropdown menu.

We will go through some of the important tools like Histogram, Dominator Tree and Leak Suspect report which can be used to identify memory leaks.

Histogram lists all the different classes loaded in your Java Application at the time of heap dump. It also lists the number of objects per class along with the shallow and retained heap size. Using the histogram, it is hard to identify which object is taking the most memory. However, we can easily identify which class type holds the largest amount of memory. For instance, in the screenshot below byte array holds the largest amount of memory. But, we cannot identify which object actually holds that byte array.

Shallow Heap v/s Retained Heap

Shallow Heap is the size of the object itself. For instance, in the screenshot below byte array itself holds the largest amount of memory.  Retained Heap is the size of the object itself as well as the size of all the objects retained in it. For instance, in the screenshot below the DogShelter object itself holds a size of 16 bytes. However, it has a retained heap size of more than 305Mb which means it likely holds the byte array which contributes to the very large retained heap size.

Finally, from the Histogram, we infer that the problem suspect is byte[] which is retained by the object of class DogShelter or Dog.

Dominator Tree

The dominator tree of the Java objects allows you to easily identify object holding the largest chunk of memory. For instance, we can see from the snipped below that the Main Thread object holds the largest memory. On collapsing the main thread tree we can see that the instance of class DogShelter holds a hashmap holding over 300Mb of memory.

Dominotart tree is useful when you have a single object that is eating up a large amount of memory. The Dominator tree wouldn’t make much sense if multiple small objects are leading to a memory leak. In that case, it would be better to use the Histogram to find out the instances of classes that consume the most amount of memory.

From the Dominator Tree, we infer that the problem suspect is the DogShelter class.

Duplicate Classes

The duplicate class tab will list down the classes that are loaded multiple times. If you are using ClassLoaders in your code you can use the Duplicate Classes to ensure that the code is functioning properly and classes are not loaded multiple times.

Leak Suspect

Finally, the Leak suspect report runs a leak suspect query that analyzes the Heap dump and tries to find the memory leak. For non-trivial memory leaks, the Leak suspect query may not be able to identify the memory leak and it’s up to the developer with the knowledge of the program to pinpoint the leak using the tools discussed above.

Since we had a very trivial memory leak, the inference that we derived manually using Histogram and Dominator Tree is the same as the inference from the leak suspect report as seen below.

• Configuring your system
• JIT Compiler
• JITServer technology
• JITServer tuning
• AOT Compiler
• Java Attach API
• System dump
• Java 11 API
• Java 17 API
• Java 21 API
• Java 22 API

Heap dumps contain a snapshot of all the live objects that are being used by a running Java™ application on the Java heap. You can obtain detailed information for each object instance, such as the address, type, class name, or size, and whether the instance has references to other objects.

There are two formats for heap dumps; the classic format and the Portable Heap Dump (PHD) format, which is the default. Whilst the classic format is generated in ascii text and can be read, the PHD format is binary and and must be processed for analysis.

Obtaining dumps

Heap dumps are generated by default in PHD format when the Java heap runs out of space. If you want to trigger the production of a heap dump in response to other situations, or in classic format, you can use one of the following options:

• Configure the heap dump agent. For more information, see the -Xdump option.
• Use the com.ibm.jvm.Dump API programmatically in your application code. For more information, see the JVM diagnostic utilities API documentation .

Analyzing dumps

The best method to analyze a PHD heap dump is to use the Eclipse Memory Analyzer™ tool (MAT) or the IBM Memory Analyzer tool . These tools process the dump file and provide a visual representation of the objects in the Java Heap. Both tools require the Diagnostic Tool Framework for Java (DTFJ) plugin. To install the DTFJ plugin in the Eclipse IDE, select the following menu items:

The following sections contain detailed information about the content of each type of heap dump file.

Portable Heap Dump (PHD) format

A PHD format dump file contains a header section and a body section. The body section can contain information about object, array, or class records. Primitive numbers are used to describe the file format, as detailed in the following table:

General structure

The following structure comprises the header section of a PHD file:

• A UTF string indicating that the file is a portable heap dump
• An int containing the PHD version number
• 1 indicates that the word length is 64-bit.
• 2 indicates that all the objects in the dump are hashed. This flag is set for heap dumps that use 16-bit hash codes. Eclipse OpenJ9™ heap dumps use 32-bit hash codes that are created only when used. For example, these hash codes are created when the APIs Object.hashCode() or Object.toString() are called in a Java application. If this flag is not set, the presence of a hash code is indicated by the hash code flag on the individual PHD records.
• 4 indicates that the dump is from an OpenJ9 VM.
• A byte containing a tag with a value of 1 that indicates the start of the header.
• header tag 1 - not used
• header tag 2 - indicates the end of the header
• header tag 3 - not used
• header tag 4 - indicates the VM version (Variable length UTF string)

The body of a PHD file is indicated by a byte that contains a tag with a value of 2, after which there are a number of dump records. Dump records are preceded by a 1 byte tag with the following record types:

• Short object: 0x80 bit of the tag is set
• Medium object: 0x40 bit of the tag is set (top bit value is 0)
• Primitive Array: 0x20 bit if the tag is set (all other tag values have the top 3 bits with a value of 0)
• Long record: tag value is 4
• Class record: tag value is 6
• Long primitive array: tag value is 7
• Object array: tag value is 8

These records are described in more detail in the sections that follow.

The end of the PHD body is indicated by a byte that contains a tag with a value of 3.

Object records

Object records can be short, medium, or long, depending on the number of object references in the heap dump.

1. Short object record

The following information is contained within the tag byte:

The 1 byte tag, which consists of the following bits:

A byte or a short containing the gap between the address of this object and the address of the preceding object. The value is signed and represents the number of 32-bit words between the two addresses. Most gaps fit into 1 byte.

• If all objects are hashed, a short containing the hash code.
• The array of references, if references exist. The tag shows the number of elements, and the size of each element. The value in each element is the gap between the address of the references and the address of the current object. The value is a signed number of 32-bit words. Null references are not included.

2. Medium object record

These records provide the actual address of the class rather than a cache index. The following format is used:

The 1 byte tag, consisting of the following bits:

A byte or a short containing the gap between the address of this object and the address of the preceding object (See the Short object record description)

• A word containing the address of the class of this object.
• The array of references (See the Short object record description).

3. Long object record

This record format is used when there are more than 7 references, or if there are extra flags or a hash code. The following format is used:

The 1 byte tag, containing the value 4.

A byte containing flags, consisting of the following bits:

A byte , short , int , or long containing the gap between the address of this object and the address of the preceding object (See the Short object record description).

• If all objects are hashed, a short containing the hash code. Otherwise, an optional int containing the hash code if the hashed and moved bit is set in the record flag byte.
• An int containing the length of the array of references.

Array records

PHD arrays can be primitive arrays or object arrays, as described in the sections that follow.

1. Primitive array record

The following information is contained in an array record:

byte , short , int or long containing the gap between the address of this object and the address of the preceding object (See the Short object record description).

• byte , short , int or long containing the array length.
• An unsigned int containing the size of the instance of the array on the heap, including header and padding. The size is measured in 32-bit words, which you can multiply by four to obtain the size in bytes. This format allows encoding of lengths up to 16GB in an unsigned int .

2. Long primitive array record

This type of record is used when a primitive array has been hashed.

The 1 byte tag with a value of 7.

A byte containing the following flags:

a byte or word containing the gap between the address of this object and the address of the preceding object (See the Short object record description).

• a byte or word containing the array length.

3. Object array record

The following format applies:

The 1 byte tag with a value of 8.

A byte , short , int or long containing the gap between the address of this object and the address of the preceding object (See the Short object record format description).

• A word containing the address of the class of the objects in the array. Object array records do not update the class cache.
• If all objects are hashed, a short containing the hash code. If the hashed and moved bit is set in the records flag, this field contains an int .
• An final int value is shown at the end. This int contains the true array length, shown as a number of array elements. The true array length might differ from the length of the array of references because null references are excluded.

Class records

The PHD class record encodes a class object and contains the following format:

The 1 byte tag, containing the value 6.

A byte, short , int or long containing the gap between the address of this class and the address of the preceding object (See the Short object record description).

• An int containing the instance size.
• A word containing the address of the superclass.
• A UTF string containing the name of this class.
• An int containing the number of static references.
• The array of static references (See the Short object record description).

Classic Heap Dump format

Classic heap dumps are produced in ascii text on all platforms except z/OS, which are encoded in EBCDIC. The dump is divided into the following sections:

Header record

A single string containing information about the runtime environment, platform, and build levels, similar to the following example:

A record of each object instance in the heap with the following format:

The following object types ( object type ) might be shown:

• class name (including package name)
• class array type
• primitive array type

These types are abbreviated in the record. To determine the type, see the Java VM Type Signature table .

Any references found are also listed, excluding references to an object's class or NULL references.

The following example shows an object instance (16 bytes in length) of type java/lang/String , with a reference to a char array:

The object instance (length 32 bytes) of type char array, as referenced from the java/lang/String , is shown in the following example:

The following example shows an object instance (24 bytes in length) of type array of java/lang/String :

A record of each class in the following format:

The following class types ( <class type> ) might be shown:

• primitive array types

Any references found in the class block are also listed, excluding NULL references.

The following example shows a class object (80 bytes in length) for java/util/Date , with heap references:

Trailer record 1

A single record containing record counts, in decimal.

For example:

Trailer record 2

A single record containing totals, in decimal.

The values in the example reflect the following counts:

• 7147 total objects
• 22040 total references
• (12379) total NULL references as a proportion of the total references count

Java VM Type Signatures

The following table shows the abbreviations used for different Java types in the heap dump records:

• DTFJ interface

.PHD File Extension

• 1. PhotoDirector Project File
• 2. Portable Heap Dump File

PhotoDirector Project File

What is a phd file.

Photo project created by PhotoDirector, a program used for editing digital photos; supports imported photos from many different camera RAW formats, including .DNG , .CR2 , .SRF , and many others; contains the library of imported images and stores any user edits; used as the native project save format and is saved with other data files and folders that contain the digital photo data.

Programs that open PHD files

Portable heap dump file.

Data file created in the Portable Heap Dump format, which is used to create Java heap dump files using IBM's version of the Java Virtual Machine (JVM); may contains a record of all Java heap objects; used for debugging application errors such as memory leaks.

More Information

Portable heap dumps can be generated by setting the following environment variable parameters: IBM_HEAP_DUMP=true and IBM_HEAPDUMP=true . PHD files may be saved in a text or a binary format. However, the binary format is much smaller in file size. To specify the text format, set the IBM_JAVA_HEAPDUMP_TEXT=true environment variable.

NOTE: Portable heap dumps are typically generated by killing a running Java application. Therefore, to create a PHD file, start your Java program with the required environment variables set and then kill it.

Programs that open or reference PHD files

Verified by fileinfo.com.

The FileInfo.com team has independently researched all file formats and software programs listed on this page. Our goal is 100% accuracy and we only publish information about file types that we have verified.

If you would like to suggest any additions or updates to this page, please let us know .

PAGE CONTENTS

• Manage Email Subscriptions
• How to Post to DZone
• Article Submission Guidelines
• Manage My Drafts

Spark + Kafka for Real-Time Machine Learning: Join us May 29 to learn more about real-time ML and how to solve challenges data teams face.

Data Engineering: Work with DBs? Build data pipelines? Or maybe you're exploring AI-driven data capabilities? We want to hear your insights.

Modern API Management : Dive into APIs’ growing influence across domains, prevalent paradigms, microservices, the role AI plays, and more.

PostgreSQL: Learn about the open-source RDBMS' advanced capabilities, core components, common commands and functions, and general DBA tasks.

• Java Thread Dump Analysis
• Problems With Nested CompletableFuture in Java
• Achieving Inheritance in NoSQL Databases With Java Using Eclipse JNoSQL
• Mastering Exception Handling in Java CompletableFuture: Insights and Examples
• Software Testing as a Debugging Tool
• CAP Theorem for Distributed System
• Securing Secrets: A Guide To Implementing Secrets Management in DevSecOps Pipelines
• Top 10 Essential Linux Commands

Java Heap Dump Analyzer

Learn about heap and garbage collection in java applications and how to take the heap dump of an application and analyze it in eclipse memory analyzer..

Join the DZone community and get the full member experience.

Identifying the reason for an OutOfMemory error in Java applications with a larger heap size is a nightmare for a developer, because most of the OutOfMemory situations may not be identified during the testing phase. It may occur only in production after running for a long time. The purpose of this article is to explain the use of a heap analyzer tool to identify a memory leakage in larger enterprise Java applications, which use a larger size of heaps. Before going to the details, we will discuss the following points:

Garbage Collection

Outofmemory, what is heap.

The space used by the Java Runtime to allocate memory to Objects and JRE Classes is called Heap. The heap space can be configured using the following JVM arguments:

• -Xmx<size> — Setting maximum Java heap size
• -Xms<size> — Setting initial Java heap size

The maximum heap size that can be configured in a 32 bit JVM is 2GB. If any application requires more than 2 GB, it should run on 64 bit JVM. 64MB is the maximum heap size by default.

One of the advantages of Java over C++ is automatic memory management. In C++, memory can be released manually, but it will happen automatically in Java using a process called garbage collection. Garbage collection will free up the memory of an object that doesn’t have any reference; it will destroy unused objects. The garbage collection process can be tuned for different applications based on the object creation characteristics of the application. This can be achieved through a number of JVM arguments. Following are a few JVM arguments which can be used to tune the garbage collection process:

GC Execution has a direct relationship with the size of the Heap.

• Larger Heap size will increase the GC execution time, but decrease the number of GC executions.
• Smaller Heap Size will increase the number of GC executions, but decrease the GC execution time

A java.lang.OutOfMemoryError will occur when the application tries to add more objects into the heap and there is no space left. This will happen when the maximum heap size set in the start of the application is filled with objects and the garbage collector is not able to free up the memory because the all objects in heap still have some references. This may happen because of two reasons:

The application may need more memory to run; the currently allocated heap size is not enough to accommodate the objects generated during the runtime.

Due to a coding error in the application which is keeping the references of unwanted objects.

The solution for the first reason is to increase the heap size. The solution for the second is to analyze the code flow and heap dump to identify the unwanted objects in heap. To analyze the application heap, we need to take the heap dump and open it in a memory analyzing tool.

In this article, we will discuss on how to take the heap dump of an application running on Oracle Java and analyze it  in Eclipse Memory Analyzer .

How to Take Heap Dump

Heap dump can be taken in two ways:

• A JVM argument can be added to generate heap dump whenever an OutOfMemoryError occurs.

The  -XX:+HeapDumpOnOutOfMemoryError option can be added to generate a heap dump on OutOfMemoryError. By default, the heap dump is created in a file called java_pid pid .hprof in the working directory of the VM, but we can set an alternative path using the JVM option  -XX:HeapDumpPath=path .  

• Using a jmap tool available with JDK. The following command can be executed from the command line:

  jmap -dump:format=b,file=heap.bin <pid>  

"<pid>" can be replaced with the process id of the application.

Eclipse Memory Analyzer

Eclipse Memory Analyzer can download from eclipse.org .

Unzip the downloaded file and double click "MemoryAnalyzer" to start the application.

Execute a Java program which is continuously running.

Take heap dump using jmap:

  jmap -dump:format=b,file=heap.bin 6920  

In Linux, to identify the process id, use  ps –ef | grep java .

Open the heap dump in Eclipse Memory Analyzer using the option File --> Open Heap Dump.

First, it will prompt you to create a leak suspect report. The user can create it or skip it.

The "overview" tab of the memory analyzer will show the total size of the heap and a pie chart of object size.

Click on the highest value in the pie chart and select List Objects --> with outgoing references.

It will open a new tab, " List Objects ," and expand the tree structure of the object.

The user can expand and find the objects available in heap. In this example, the HeapLoader object consist of a list of School objects, and school objects consist of a list of students.

School List in HeapLoader

Each school object in List and its attributes

Student object in school and its attribute

There is an option available in Eclipse Memory Analyzer to Acquire Heap Dump if the application is running on the same machine. Select File --> Acquire Heap Dump to show all Java applications available on the machine. Select the process, browse the path where you want the heap to save. and click "finish."

These are the basic steps to analyze a heap dump. There are more options available in Memory Analyzer, which will give more insight into the heap dump. Eclipse Heap Analyzer can be used for the dumps generated from an application running on Oracle Java.

Sample Application for Testing

The sample application used in the above example consists of two objects, School and Student. Details about the sample application are available here .

https://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html

https://www.eclipse.org/mat/downloads.php

Published at DZone with permission of Sudeep C M . See the original article here.

Opinions expressed by DZone contributors are their own.

Partner Resources

• About DZone
• Send feedback
• Community research
• Advertise with DZone

CONTRIBUTE ON DZONE

• Become a Contributor
• Core Program
• Visit the Writers' Zone
• Terms of Service
• Privacy Policy
• 3343 Perimeter Hill Drive
• Nashville, TN 37211
• [email protected]

Let's be friends:

• Manage Cookies
• Working Groups
• Marketplace
• Planet Eclipse
• Report a Bug
• Mailing Lists
• Documentation
• Getting Started / Support
• How to Contribute
• IDE and Tools
• Newcomer Forum

Participate

Eclipse IDE

Breadcrumbs

• Eclipse Wiki

MemoryAnalyzer

Notice: this wiki is now read only and edits are no longer possible. please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/wiki-shutdown-plan for the plan..

• View source
• 2.1 Installation
• 2.2 Basic Tutorials
• 2.3 Further Reading
• 3.1 HPROF dumps from Sun Virtual Machines
• 3.2 System Dumps and Heap Dumps from IBM Virtual Machines
• 3.3 What if the Heap Dump is NOT Written on OutOfMemoryError?
• 4 Extending Memory Analyzer

The Eclipse Memory Analyzer tool (MAT) is a fast and feature-rich heap dump analyzer that helps you find memory leaks and analyze high memory consumption issues.

With Memory Analyzer one can easily

• find the biggest objects, as MAT provides reasonable accumulated size (retained size)
• explore the object graph, both inbound and outbound references
• compute paths from the garbage collector roots to interesting objects
• find memory waste, like redundant String objects, empty collection objects, etc...

Getting Started

Installation.

See the download page for installation instructions.

Basic Tutorials

Both the Basic Tutorial chapter in the MAT documentation and the Eclipse Memory Analyzer Tutorial by Lars Vogel are a good first reading, if you are just starting with MAT.

Further Reading

Check MemoryAnalyzer/Learning Material . You will find there a collection of presentations and web articles on Memory Analyzer, which are also a good resource for learning. These pages Querying Heap Objects (OQL) OQL Syntax MemoryAnalyzer/OQL also explain some of the ways to use Object Query Language (OQL)

Getting a Heap Dump

Hprof dumps from sun virtual machines.

The Memory Analyzer can work with HPROF binary formatted heap dumps . Those heap dumps are written by Sun HotSpot and any VM derived from HotSpot. Depending on your scenario, your OS platform and your JDK version, you have different options to acquire a heap dump.

Non-interactive

If you run your application with the VM flag -XX:+HeapDumpOnOutOfMemoryError a heap dump is written on the first Out Of Memory Error. There is no overhead involved unless a OOM actually occurs. This flag is a must for production systems as it is often the only way to further analyze the problem.

As per this article , the heap dump will be generated in the "current directory" of the JVM by default. It can be explicitly redirected with -XX:HeapDumpPath= for example -XX:HeapDumpPath=/disk2/dumps . Note that the dump file can be huge, up to Gigabytes, so ensure that the target file system has enough space.

Interactive

As a developer, you want to trigger a heap dump on demand. On Windows, use JDK 6 and JConsole . On Linux and Mac OS X , you can also use jmap that comes with JDK 5.

• tutorial here

Via Java VM parameters:

• -XX:+HeapDumpOnOutOfMemoryError writes heap dump on OutOfMemoryError (recommended)
• -XX:+HeapDumpOnCtrlBreak writes heap dump together with thread dump on CTRL+BREAK
• -agentlib:hprof=heap=dump,format=b combines the above two settings (old way; not recommended as the VM frequently dies after CTRL+BREAK with strange errors)
• Sun (Linux, Solaris; not on Windows) JMap Java 5 : jmap -heap:format=b <pid>
• Sun (Linux, Solaris; Windows see link) JMap Java 6 : jmap.exe -dump:format=b,file=HeapDump.hprof <pid>
• Sun (Linus, Solaris) JMap with Core Dump File: jmap -dump:format=b,file=HeapDump.hprof /path/to/bin/java core_dump_file
• Sun JConsole: Launch jconsole.exe and invoke operation dumpHeap() on HotSpotDiagnostic MBean
• SAP JVMMon: Launch jvmmon.exe and call menu for dumping the heap

Heap dump will be written to the working directory.

System Dumps and Heap Dumps from IBM Virtual Machines

Memory Analyzer may read memory-related information from IBM system dumps and from Portable Heap Dump (PHD) files with the IBM DTFJ feature installed. Once installed, then File > Open Heap Dump should give the following options for the file types:

• All known formats
• HPROF binary heap dumps
• IBM 1.4.2 SDFF
• IBM Javadumps
• IBM SDK for Java (J9) system dumps
• IBM SDK for Java Portable Heap Dumps

For a comparison of dump types, see Debugging from dumps . System dumps are simply operating system core dumps; therefore, they are a superset of portable heap dumps. System dumps are far superior than PHDs, particularly for more accurate GC roots, thread-based analysis, and unlike PHDs, system dumps contain memory contents like HPROFs. Older versions of IBM Java (e.g. < 5.0SR12, < 6.0SR9) require running jextract on the operating system core dump which produced a zip file that contained the core dump, XML or SDFF file, and shared libraries. The IBM DTFJ feature still supports reading these jextracted zips; however, newer versions of IBM Java do not require jextract for use in MAT since DTFJ is able to directly read each supported operating system's core dump format. Simply ensure that the operating system core dump file ends with the .dmp suffix for visibility in the MAT Open Heap Dump selection. It is also common to zip core dumps because they are so large and compress very well. If a core dump is compressed with .zip , the IBM DTFJ feature in MAT is able to decompress the ZIP file and read the core from inside (just like a jextracted zip). The only significant downsides to system dumps over PHDs is that they are much larger, they usually take longer to produce, they may be useless if they are manually taken in the middle of an exclusive event that manipulates the underlying Java heap such as a garbage collection, and they sometimes require operating system configuration ( Linux , AIX ) to ensure non-truncation.

In recent versions of IBM Java (> 6.0.1), by default, when an OutOfMemoryError is thrown, IBM Java produces a system dump, PHD, javacore, and Snap file on the first occurrence for that process (although often the core dump is suppressed by the default 0 core ulimit on operating systems such as Linux). For the next three occurrences, it produces only a PHD, javacore, and Snap. If you only plan to use system dumps, and you've configured your operating system correctly as per the links above (particularly core and file ulimits), then you may disable PHD generation with -Xdump:heap:none. For versions of IBM Java older than 6.0.1, you may switch from PHDs to system dumps using -Xdump:system:events=systhrow,filter=java/lang/OutOfMemoryError,request=exclusive+prepwalk -Xdump:heap:none

In addition to an OutOfMemoryError, system dumps may be produced using operating system tools (e.g. gcore in gdb for Linux, gencore for AIX, Task Manager for Windows, SVCDUMP for z/OS, etc.), using the IBM Java APIs , using the various options of -Xdump , using Java Surgery , and more.

Versions of IBM Java older than IBM JDK 1.4.2 SR12, 5.0 SR8a and 6.0 SR2 are known to produce inaccurate GC root information.

What if the Heap Dump is NOT Written on OutOfMemoryError?

Heap dumps are not written on OutOfMemoryError for the following reasons:

• Application creates and throws OutOfMemoryError on its own
• Another resource like threads per process is exhausted
• C heap is exhausted

As for the C heap, the best way to see that you won't get a heap dump is if it happens in C code (eArray.cpp in the example below):

C heap problems may arise for different reasons, e.g. out of swap space situations, process limits exhaustion or just address space limitations, e.g. heavy fragmentation or just the depletion of it on machines with limited address space like 32 bit machines. The hs_err-file will help you with more information on this type of error. Java heap dumps wouldn't be of any help, anyways.

Also please note that a heap dump is written only on the first OutOfMemoryError. If the application chooses to catch it and continues to run, the next OutOfMemoryError will never cause a heap dump to be written!

Extending Memory Analyzer

Memory Analyzer is extensible, so new queries and dump formats can be added. Please see MemoryAnalyzer/Extending_Memory_Analyzer for details.

• Tools Project
• Memory Analyzer

This page was last modified 07:12, 28 December 2022 by Eclipsepedia anonymous user Unnamed Poltroon .

Back to the top