Visit Azul.com Support

Azul Platform Prime Memory Management

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

This section provides an overview of Azul Zing Builds of OpenJDK (Zing) memory management processes. It covers the following topics:

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:

  • Java heap use

  • Reserved memory

Note
Using Azul technology, Java Application Execution uses all available memory without consequences common to tasks such as garbage collection and heap memory compaction. With Azul Platform Prime you can allocate 100 GBs of memory to easily and effectively enhance your enterprise production workloads.

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.

  • HotSpot command line options unsupported by Zing

    If Zing detects a HotSpot VM native command line option that it does not support, its response can be set with the following option:

     
    -Xnativevmflags:[ignore|error|warn]

    The default option is ignore.

    If -Xnativevmflags:error is specified and Zing detects an option that it does not support, it does not launch and generates the following type of message:

     
    HotSpot™ 64-Bit Tiered VM error: Unsupported native VM option ‘+UseParNewGC’
  • Zing commands not implemented by HotSpot

    For command line options that are not implemented by the HotSpot VM (including options specific to Zing), the response is determined by the following option:

     
    –Xflags:[ignore|error|warn]

    The default setting is error. The error setting ensures that unrecognized options are highlighted when Zing is used. For example, if the incorrectly formatted option –XXMaxPermS=128m is detected, Zing does not launch and generates the message:

     
    HotSpot ™ 64-Bit Tiered VM error: Unrecognized VM option ‘MaxPermS=128m’
  • HotSpot or Open JDK XX:+UseLargePages

    If you are running Oracle HotSpot or OpenJDK and using XX:+UseLargePages, you must choose one of the following options to run Zing:

    • Disable the hugepages facility on your Linux system when you are running Zing.

    • Ensure there is sufficient memory allocated to each: Zing, hugepages, and Linux memory.

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:

SystemZingReservableMemory reserve at config policy

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.

System Reserve at config ReservedMem ContingencyMem PausePreventMem
reserve at launch 5.21

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.

MemReserve Reserve at Launch ZVM

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.

MemReserve Reserve at Launch ZVM

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.