Azul Platform Prime Memory Management

Zing Garbage Collector

The Zing Garbage Collector is an updated generational form of the Azul Pauseless Garbage Collection Algorithm and is the only collector of Zing. Zing’s Garbage Collector differentiates itself from other generational garbage collectors by supporting simultaneous – generational concurrency: the different generations are collected using concurrent (non stop-the-world) mechanisms that can be simultaneously and independently active.

Zing Memory Allocation

Azul Platform Prime uses Zing to run Java applications, similar to a typical JVM running a Java application. The significant difference is how memory is handled. Zing uses the Azul Zing System Tools (ZST) for managing the memory of three components: Contingency memory, Pause Prevention memory, and Zing Memory, the memory used for Zing’s Garbage Collector.

Using Zing with the Garbage Collector and Contingency memory means that your Java application is no longer limited to the maximum heap size specified on the Java command line when you started your Java application. As an additional resource, Zing’s Garbage Collector might temporarily use Pause Prevention memory to prevent pauses that are caused by lack of available clean pages.

See Understanding Zing Memory Use for additional information about how the memory resource is used and assigned in a Azul Platform Prime environment.

Adjust the memory you configure to ensure you have sufficient memory to support Zing instances:

Compatibility with HotSpot VM Command Line Options

Zing recognizes the standard and non-standard command line options for the HotSpot VM that is a core component of Java Platform, Standard Edition (Java SE) 6. See the HotSpot VM Options section in the Oracle developer site for detailed descriptions of the HotSpot VM command line options.

Understanding Memory Allocation

Azul Platform Prime uses Zing to run Java applications in the same way that other JVMs run Java applications. The significant difference between Zing and other JVMs is the management of memory. Zing uses ZST’s ZMM for managing memory for the three memory types that the JVM uses: Reservable memory, Contingency memory and Pause Prevention memory. This memory, called System Zing Memory, is configured when the ZST’s system-config-zing-memory tool is run.

Memory for use by the JVMs running on the machine can be reserved at configuration (when the tool is run) using the reserve-at-config policy or the memory reservation for each JVM can be deferred until the launch of that JVM process using the reserve-at-launch policy. For the reserve-at-launch policy, upper limits are set for the amount of System Zing Memory to use for each of the memory types, Reservable memory, Contingency memory and Pause Prevention memory.

For both configuration policies, at the launch of the JVM, the JVM requests the memory to reserve for its exclusive use as the process’s Java Heap. The JVM’s Garbage Collector manages Java objects in this memory.

When free memory in the Java Heap is low, the JVM can use memory in the Contingency and Pause Prevention memory. When memory is first low, the JVM uses Pause Prevention memory to prevent pauses that could occur during a garbage collection when a thread tries to allocate an object but no free memory is available. Over the long term, if the JVM requires additional memory on an ongoing basis then memory from Contingency memory is used. This means that your Java application is no longer limited to the maximum heap size specified on the Java command line when you started your Java application.

The following figures show the relationship hierarchy of the memory when the system has been configured using the reserve-at-config policy. Note that starting with ZST 5.21.x the default memory configuration has been changed when running the configuration tool In pre-5.21.x versions, the system-config-zing-memory tool configured the system by default with the reserve-at-config policy. When running the memory configuration tool for configuring memory for the 5.21 ZST, you must select which policy you would like to use.

Reserve-at-config

The Contingency Pool and Pause Prevention Pool are each 5% of the System Zing memory.

Note that the configuration tool in the 5.21 version of the ZST uses percentages of the total Host System memory.

When a Zing process runs, it reserves some of the Reservable Memory, based on the value of the -Xmx command-line option, as shown in the following graphic:

Reserve-at-launch

When a system is configured using the reserve-at-launch policy and no JVM instances are running, there is no System Zing Memory reserved on the system. Instead, the system-config-zing-memory tool only configures an upper limit on the amount of memory that can be reserved for System Zing Memory. If that memory in not in use as System Linux Memory then it can be used as System Zing Memory for Reservable memory, Contingency memory and Pause Prevention memory.

In pre-5.21 versions of the ZST, only an upper limit is set.

When a process is launched, memory is reserved for the Java Heap, the Contingency pool and the Pause Prevention pool.

For the pre-5.21 versions of the ZST, all of the Contingency and Pause Prevention memory is reserved from the System Zing Memory.

In the 5.21 version of the ZST, the only a small amount of the total upper limit of the Contingency and Pause Prevention memory is reserved from the System Zing Memory. By default, this is 200 MB. The ZMM strives to keep this much free memory available, even when a ZVM process requires some for its own use.

When a Zing JVM running in a reserve-at-launch configured ZST partition terminates, the System Zing Memory used by the JVM process for the Java heap is returned to System Linux memory as free memory.

Any Pause Prevention or Contingency memory used by the terminating JVM is returned to the corresponding Pause Prevention or Contingency memory pool.

If no other Zing JVM is running in the ZST partition following the termination of the JVM then any Pause Prevention or Contingency pool memory reserved in that partition will also be returned to System Linux memory as free memory.