Currently set to Index
Currently set to Follow

224% ROI and payback in under 3 months for Azul Zing.
Read Forrester’s Total Economic Impact™ Study.

Slash your Java support costs as much as 90%!
We make it easy, safe and secure.

What is Java Heap Size?

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 Azul Zing® Controls 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 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
Learn More About Azul Zing®

Customer Testimonial

“We’re achieving unobtainable technical feats with Azul Zing that you can’t achieve using plain vanilla Java. And this performance translates into huge infrastructure savings and simplification by having less servers. With Azul, we were able to reduce our front-end server footprint by more than 30%, which is hundreds of servers, and our database server footprint by about 50%.”

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.

For more on this topic, download your free copy of Understanding Java GC

The paper concludes with some pitfalls, common misconceptions, and “myths” around garbage collection behavior, as well as examples of how certain choices can result in impressive application behavior…

Get Your Copy

© Azul 2021 All rights reserved.