Visit Support

Reservable and Reserved Memory

Table of Contents
Need help?
Schedule a consultation with an Azul performance expert.
Contact Us
Looking for Zing?
The Azul Zing Virtual Machine is now Azul Zulu Prime Builds of OpenJDK and part of Azul Platform Prime.
Learn more

The Reservable memory is a portion of the System Zing Memory reserved when the reserve-at-config policy is chosen when configuring your system using the system-config-zing-memory tool. In this case, the Reservable memory is available to any Azul Zing Builds of OpenJDK (Zing) instance at launch. Specific requests for memory made by Zing are assigned to that Zing instance running a Java application. Reservable memory is assigned to new Zing instances until the available Reservable memory is insufficient to start another Zing instance. Reservable memory comprises the bulk of the System Zing Memory.

Reserved memory is the amount of memory initially allocated to a specific Zing instance when the instance starts. This is the memory the Zing instance uses as Java heap memory. The Reserved memory is reserved for each JVM instance. It guarantees space to store a minimum live set for each Zing instance plus the space to support the object creation required to support the work done in the application. The live set is the set of objects in the Java heap referenced by the Java application. The live set can also be described as the amount of memory remaining in the heap after a simultaneous new and old generation garbage collection.

Multiple Zing instances can be started on a system, each being assigned its allocated amount of Reservable memory. When a Zing instance exits, its Reservable memory is released back to the system’s Reservable memory and is available for other Zing instances.

The amount of memory allocated to a Zing instance when it starts is determined by the value of the –Xmx Java heap size command line option.

Estimating the Number of Possible Concurrent Zing Instances

When estimating the number of Zing instances running Java applications that can run concurrently on a system, determine the amount of System Zing Memory available, subtract the percentage of System Zing Memory allocated to Pause Prevention and Contingency memory, and then divide the remaining amount of System Zing Memory by the typical Java heap (-Xmx) memory that would be set for your Zing instances.

For example:

  • The configured System Zing Memory is 100 GB. The amount of memory allocated to Pause Prevention and Contingency memory is 10 GB. The remaining available System Zing Memory, the Reservable memory, is 90 GB.

  • Total the -Xmx values you will use for each of the Java applications you want to run. Remember, in a Zing environment, the -Xmx value can be large because there is no concern for garbage collection pauses

  • So, for this example, in a Zing environment where you want to maximize your Java application performance, set -Xmx to 20 GB for each Zing instance. This enables running 4 concurrent Zing instances (4 Zing instances x 20 GB in -Xmx = 80 GB consumed, with 10 GB left over from the 90 available).

In addition to the number of concurrent Zing instances, account for the number of available cores. Do not expect multiple busy Zing instances to run well on a limited number of cores. Distribute Zing instances over the available host systems.