Scribd
Upload
16 views3 pages

Java vs. Native Heap Memory Explained

This document explains the differences between the Java heap and the native (C) heap in Java processes, highlighting their separate memory management and implications for OutOfMemoryErrors. It provides troubleshooting steps for identifying memory allocation issues, particularly in 32-bit and 64-bit applications, and emphasizes the importance of configuring heap sizes appropriately. The document also references additional resources for further information on troubleshooting memory leaks and Java memory issues.

Uploaded by

nil
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
16 views3 pages

Java vs. Native Heap Memory Explained

This document explains the differences between the Java heap and the native (C) heap in Java processes, highlighting their separate memory management and implications for OutOfMemoryErrors. It provides troubleshooting steps for identifying memory allocation issues, particularly in 32-bit and 64-bit applications, and emphasizes the importance of configuring heap sizes appropriately. The document also references additional resources for further information on troubleshooting memory leaks and Java memory issues.

Uploaded by

nil
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

2/9/24, 3:08 PM Document 1355284.

1
Copyright (c) 2024, Oracle. All rights reserved. Oracle Confidential.

Understanding the Java Heap Versus the Native (C) Heap (Doc ID 1355284.1)

In this Document

Purpose
Troubleshooting Steps
References

APPLIES TO:

Java SE JDK and JRE - Version 8 and later


Information in this document applies to any platform.

PURPOSE

A Java process consists of two separate heap spaces:

Java heap
Native heap, also known as "C heap"

This can be confusing when it comes to understanding OutOfMemoryErrors and memory allocation failures. This document
explains some differences between these memory spaces and how to handle various OutOfMemoryErrors related to the C heap
and Java heap.

TROUBLESHOOTING STEPS

When you look at a Java process, there are many memory pools and consumers of the virtual process memory: Java heap and
C heap are just two. Others include the Java Virtual Machine's (JVM's) Metaspace, and Codecache, as well as thread stacks,
program stack, libraries, and others, as shown in the following diagram:

It is important to understand that Java heap and C heap are separate memory pools within the process memory.

Java heap is a memory pool used to store all the Java objects allocated by Java code.
The C heap is used to store all the native objects allocated by native code. The Hotspot JVM is essentially a C++
application, and as such, the JVM allocates C++ objects on the C heap to perform its work. Java applications may also

[Link] 1/3
2/9/24, 3:08 PM Document 1355284.1
have native components that allocate native objects on the C heap.

Java objects are never stored in the C heap and native objects are never stored in the Java heap.

Both the Java heap and the C heap require contiguous virtual process memory, also called address space (addressable memory
space). However, the sizes of the Java heap and C heap are usually very different. Also, the size of the Java heap can be
configured explicitly through java command arguments, but the C heap size is not configurable. C heap simply expands as
needed within the address space. Additionally, while the Java garbage collector manages the Java heap and clears objects
that are no longer referenced, the C heap is not managed. Memory allocated in C heap must be freed explicitly when it is no
longer needed.

A process memory map (pmap) shows the address space layout of the entire process. Within the pmap, the C heap is labeled
as heap and the Java heap is mapped in as anonymous memory, so it is labeled anon. Here, we can see two entries of a 64-
bit pmap:

0000000100400000 757760 757760 757760 - rwx---- [ heap ]


00000006C0800000 4194304 2781184 2777088 - rw----- [ anon ]

Notice the C heap starts at a very low address and the Java heap starts at an address that is 23Gb higher in the address space
(Hex: 6C0800000 - 100400000 = Dec: 23Gb). This allows the C heap to grow on demand as the application runs. Other
allocations may also get mapped between them, such as thread stacks, byte buffers, and the like.

Native OutOfMemoryErrors can occur when the C heap can no longer grow as needed within its address space. Even when
you have plenty of unused physical and swap file memory, if you're short on virtual address space, you may receive an
OutOfMemoryError. The following errors can occur particularly when the C heap has no more room to grow contiguously or an
allocation fails due to lack of available address space.

[Link]: requested 67108872 bytes for Chunk::new. Out of swap space?

# There is insufficient memory for the Java Runtime Environment to continue. # Native memory
allocation (malloc) failed to allocate 65544 bytes1

A classic example of this occurs with 32-bit Java applications, where the 32-bit process size is limited to 4Gb. This means all of
the memory consumers in the diagram above, plus operating system kernel reservations, must fit within the 4Gb limit. If the
Java heap is sized too large, there may not be enough room for the C heap to grow when needed. Consider a 32-bit
application that runs well when the Java heap is sized at 2Gb. Over time, load increases on this application now require you to
increase the Java heap size to 3Gb. However, after some days of runtime, you start getting errors like the one above.

What happened? Before the Java heap size increase, the C heap could easily have been allowed a 1Gb space ( [4Gb process
size] - [2Gb Java heap] - [1Gb C heap] = [1Gb left for everything else] ), which is plenty (let us say). After the increase, 4Gb
address space minus 3Gb Java heap leaves just 1Gb for the C heap plus all other memory pools/consumers. So when the
thread stacks, Codecache, program stack, Metaspace, etcetera, get allocated, this leaves less space for the C heap. When the
JVM attempts a native object allocation and there is no room for the C heap to expand further, a native OutOfMemoryError
occurs.

So with 32-bit applications, care must be taken to size the Java heap such that all other process memory consumers get the
portion of address space they need. If you crash with a native OutOfMemoryError, do the following:

1. Verify the HotSpot Fatal Error Log (hs_err_pid*.log) shows plenty of available physical memory and swap file space at the
time of the crash, such as the following entry:

Memory: 4k page, physical 2117891368k(993816496k free), swap 100990972k(100990972k free)

If you are out of physical or swap memory, reduce the memory load on the system or increase system or swap memory, as
appropriate. Note: Reducing the memory load may include decreasing the Java heap size(s) for the Java process or processes,
as well as reducing the number of processes and threads running on the system.

2. If the OutOfMemoryError is specific to the one process and not a system memory issue, pull a pmap from the process core
file (pmap <corefile>) to verify if the address space had been full or if the C heap did not have room to grow any further
when the crash occurred. If the OutOfMemoryError was due to a lack of address space or C heap, then decreasing the Java

[Link] 2/3
2/9/24, 3:08 PM Document 1355284.1
heap size to make more room in the address space for the C heap or other native memory allocations may be a solution. Note:
Decreasing the size of thread stacks or the sizes of other process memory pools may also be an option.

3. Verify if the OutOfMemoryError still occurs. If so, investigate whether you have a native memory leak. See Diagnosing
Native Memory Leaks. That document details how to use Native Memory Tracking to determine if the native memory growth
occurs with the JVM's native memory allocations, and for native memory leaks outside the JVM's allocations, it details which
Linux and Windows tools you can use to debug on those platforms. For native memory leak debugging on Solaris, see
"Training - How to Troubleshoot Native Memory Leak in Java Applications on Solaris with libumem" (Doc ID 1320890.1).

4. Move the application to a 64-bit JVM and 64-bit operating system when the application has outgrown the 32-bit address
space limitation. In this case, there is no memory leak and the size of the Java heap and JVM's other memory pools cannot be
reduced.

With 64-bit applications, running out of address space is usually not a problem, but if the Java heap is based too low in the
address space, the C heap may run out of room to grow. This can occur more often when CompressedOops is enabled and
the maximum Java heap size is less than 4Gb. See Running on a 64bit platform and still running out of memory for details and
possible solutions. Just as with 32-bit, 64-bit applications may also encounter continuous growth of the native memory. Use
the same process described above to troubleshoot for that case.

Particular to the Java heap space, you may encounter the following OutOfMemoryErrors:

[Link]: Java heap space

[Link]: GC overhead limit exceeded

Unlike native OutOfMemoryErrors that can occur if the Java heap is sized too large, these errors are almost always due to the
Java heap being sized too small. The troubleshooting protocol is to first increase the Java heap size and determine if the
problem is just delayed or is resolved. If it is resolved, the heap was sized too small. If the problem persists, then you may be
looking at a Finalization issue or a Java object leak, which are less common.

This document has described the differences between the Java heap and native heap within a Java process, how one can
affect the other, and some of the problems and considerations when managing the native and Java memory for your
applications. For additional information on these topics, see the following presentations:

Troubleshooting Native Memory Leaks in Java Applications

Troubleshooting Java Memory Issues

1This error can also mean the system is out of physical memory.

REFERENCES
NOTE:1320890.1 - Training - How to Troubleshoot Native Memory Leak in Java Applications on Solaris with libumem
NOTE:1274390.1 - JVM Crash: "[Link]: requested 32756 bytes for ChunkPool::allocate. Out of swap
space?"
Didn't find what you are looking for?

[Link] 3/3

Common questions

Powered by AI

Careful consideration of Java Heap size is critical in Java memory management because the heap must be large enough to handle the application's object allocation. However, if it's oversized, it can limit the address space available for the C Heap and other memory pools, potentially causing native OutOfMemoryErrors . Conversely, an undersized heap can trigger Java Heap OutOfMemoryErrors or GC overhead limit exceeded errors, as it won't accommodate objects generated under load . Balancing the heap size effectively prevents these memory allocation issues and optimizes application performance and efficiency .

Native OutOfMemoryErrors occur when the C Heap runs out of room to grow due to insufficient contiguous address space and not because of physical memory shortage . Troubleshooting such errors involves verifying the availability of address space using tools like pmap and possibly reducing the Java Heap size or native memory allocations to allow more space for the C Heap . In contrast, Java Heap OutOfMemoryErrors usually result from the heap being sized too small to handle the application load, often resolved by increasing the Java Heap size . Further investigation for lingering issues may involve checking for Java object leaks or finalization problems .

The structural difference between the Java Heap and the C Heap within a Java process lies in their memory management and purpose. The Java Heap is used to store Java objects and is managed by the Java garbage collector, which automatically clears objects no longer referenced. It can be explicitly sized, allowing developers to control its size via Java command arguments . In contrast, the C Heap is used for native objects allocated by native code, is not managed by automatic garbage collection, and must be manually freed. Although its size is not directly configurable and expands as needed within the address space, this can lead to potential OutOfMemoryErrors if it runs out of contiguous space, especially in 32-bit applications . This structural distinction affects performance, as improper management or sizing can lead to memory allocation failures that can crash applications if the heaps do not have enough room to grow .

The process memory map (pmap) is crucial in diagnosing memory allocation issues as it provides a detailed layout of the address space used by a process, showing how memory is distributed among the Java Heap, C Heap, and other memory consumers . Specifically, it can reveal the start addresses of various memory pools, indicating how memory is contiguous or fragmented, which is essential for understanding memory allocation failures or OutOfMemoryErrors. For example, by examining pmap entries, one can determine if the C Heap lacks room to grow or if the Java Heap is consuming excessive address space, leading to allocations failing .

Java's Garbage Collector (GC) plays a key role in memory management by automatically managing the lifecycle of objects in the Java Heap, freeing memory from objects that are no longer in use. This reduces the need for manual memory management and mitigates memory leaks within the Java Heap . However, the GC process can impact application performance and responsiveness, especially during ‘stop-the-world’ events when it pauses application threads to reclaim memory, affecting scalability under heavy load. GC tuning and choosing appropriate garbage collection algorithms can help optimize performance by reducing pause times and improving throughput .

A Java application on a 32-bit platform might experience OutOfMemoryErrors due to the 4Gb virtual address space limitation, which must accommodate all memory consumers, including the Java Heap, C Heap, thread stacks, and JVM's other memory pools. If the Java Heap is sized too large, it can leave insufficient room for the C Heap and other native memory allocations . Solutions include reducing the Java Heap size to free up address space for other consumers or switching to a 64-bit platform, which eliminates this address space limitation .

When a native memory leak is suspected, the first strategy is to use Native Memory Tracking (NMT) within the JVM to monitor and record native memory allocation patterns . This helps in identifying abnormal growths in native memory usage. For platform-specific insight, different tools can be utilized, such as Linux and Windows diagnostic tools to analyze and trace memory allocations outside JVM’s control. On Solaris, libumem is recommended for in-depth native memory troubleshooting, including tracking the allocation and deallocation of native memory blocks . These tools are pivotal in pinpointing the exact causes of leaks and implementing corrective measures.

Switching from a 32-bit to a 64-bit JVM can resolve OutOfMemoryErrors by removing the 4Gb address space limitation inherent in 32-bit systems, thus providing more room for memory pools to grow without crowding . However, on a 64-bit platform, it is crucial to ensure the Java Heap is not set too low in the address space, which can restrict the C Heap from expanding adequately. Additionally, new considerations include appropriately managing CompressedOops settings when the Java Heap size is below 4Gb, as this can influence memory layout and performance .

Diagnosing Java object leaks involves monitoring memory usage patterns to identify unexplained increases in memory consumption over time. Tools like heap dumps and profiling tools are essential for examining which objects remain retained in memory and fail to be garbage collected due to lingering references. To resolve leaks, developers should analyze code to locate and eliminate unnecessary object references, ensure proper closure of resources, and look to optimize data structures and algorithms to reduce memory footprint. Periodically reviewing and refactoring code can preemptively address potential leaks and improve overall application health .

The configuration of thread stacks and non-heap memory components significantly influences the performance and stability of Java applications. Excessively large thread stack sizes can deplete address space and contribute to native OutOfMemoryErrors, especially in environments with numerous threads. Conversely, small thread stack sizes could lead to stack overflows. Developers must balance these settings to ensure efficient memory utilization while avoiding allocation issues. Adjusting non-heap memory pool sizes such as Metaspace must also be carefully considered, especially in high-load scenarios, to maintain a smooth allocation process and application reliability .

You might also like