The Java heap is the area of memory used to store objects instantiated by applications running on the JVM. When the JVM is started, heap memory is created and any objects in the heap can be shared between threads as long as the application is running. The size of the heap can vary, so many users restrict the Java heap size to 2-8 GB in order to minimize garbage collection pauses.
Difference Between Heap and Stack
While heap is an important part of the memory management process, it works alongside stack for the execution of a program. Compared to heap, stack is only used for the execution of a single thread versus being globally accessible and shared with all threads. Stack memory uses a LIFO (last-in first-out) structure with each stack containing method specific values. When the method ends, the block becomes erased and is available for the next method. Heap on the other hand does not follow any order and dynamically manages memory blocks.
Types of Applications where Heap Space Matters
- In-Memory Computing
- NoSQL Databases
- Big Data Applications
- Web Personalization
Increasing Java Heap Size with Azul Platform Prime®
JVMs can easily make use of a 100 GB heap but pause times for GC can be many minutes in length. This limits application performance and scalability and prevents Java applications from using the full resources of today’s commodity servers. Very large heap sizes are often very practical, if you can eliminate the associated performance issues. Azul Platform Prime® (Formerly Azul Zing) is the first JVM to solve the problem of GC pauses and allow you to increase heap size up to 8 TB without performance penalty.
A larger Java memory heap
- Does not require working data to be divided across multiple JVM instances
- Allows more objects to be created
- Takes longer to fill
- Allows the application to run longer between garbage collection (GC) events
A smaller Java memory heap
- Holds fewer objects
- Fills more quickly
- Is garbage collected more frequently (but the pauses are shorter)
- May lead to out-of-memory errors
Is 2 – 8 GB of Memory Heap enough for most Java Applications?
We’ve found plenty of evidence to indicate the pent-up demand for more heap:
- Common use of “lateral scale” within machines
- Use of “external” memory with growing data sets (bigger databases and giuse of external data caches like memcached, JCache and JavaSpaces)
- Continuous work on the never-ending distribution problem
The problem is in the software stack, which places artificial constraints on memory per instance. GC pause time is the only limiting factor for instance size, and as we’ve found in practice, even extensive garbage collection (GC) tuning doesn’t make it go away. Once you’ve solved GC, you’ve solved the problem. Azul’s innovative C4 garbage collection algorithm is fully concurrent, eliminating the performance impact of very large heaps.