Have your Oracle Java costs gone through the roof?
Join the hundreds of 😊 customers who have made the Switch to Azul.

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

  • A larger Java memory heap
    • 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 use 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 Java Garbage Collection Whitepaper


© Azul 2020 All rights reserved.