The Java heap is the area of memory used to store objects instantiated by applications running on the JVM. Objects in the heap can be shared between threads. Many users restrict the Java heap size to 2-8 GB in order to minimize garbage collection pauses.
Types of Applications where Heap Size Matters
- In-Memory Computing
- NoSQL Databases
- Big Data Applications
- Web Personalization
How Does Azul Platform Prime Control Java Heap Size?
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 heaps 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.