Azul Platform Prime Memory Management
- Azul Zulu Prime JVM Garbage Collector
- Zing Memory Allocation
- Compatibility with HotSpot VM Command Line Options
- Understanding Memory Allocation
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 Zulu Prime Builds of OpenJDK (Azul Zulu Prime JVM) memory management processes. It covers the following topics:
Azul Zulu Prime JVM Garbage Collector
The Azul Zulu Prime JVM Garbage Collector is an updated generational form of the Azul Pauseless Garbage Collection Algorithm and is the only collector of Azul Zulu Prime JVM. The Azul Zulu Prime JVM’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 the Azul Zulu Prime JVM to run Java applications, similar to a typical JVM running a Java application. The significant difference is how memory is handled. Azul Zulu Prime JVM uses the Azul Zulu Prime System Tools (ZST) for managing the memory of three components: Contingency memory, Pause Prevention memory, and Zing Memory, the memory used for the Azul Zulu Prime JVM’s Garbage Collector.
Using Azul Zulu Prime JVM with the Garbage Collector and Con tingency 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, Azul Zulu Prime JVM’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 Azul Zulu Prime JVM instances:
Java heap use
|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
The Azul Zulu Prime JVM 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 Azul Zulu Prime JVM
If the Azul Zulu Prime JVM 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] [source, shell,opts="user,check"]
The default option is ignore.
-Xnativevmflags:erroris specified and the Azul Zulu Prime JVM 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’
Azul Zulu Prime JVM commands not implemented by HotSpot
For command line options that are not implemented by the HotSpot VM (including options specific to the Azul Zulu Prime JVM), the response is determined by the following option:
The default setting is
errorsetting ensures that unrecognized options are highlighted when the Azul Zulu Prime JVM is used. For example, if the incorrectly formatted option
–XXMaxPermS=128mis detected, the Azul Zulu Prime JVM does not launch and generates the message:
HotSpot ™ 64-Bit Tiered VM error: Unrecognized VM option ‘MaxPermS=128m’
HotSpot or Open JDK
If you are running Oracle HotSpot or OpenJDK and using
XX:+UseLargePages, you must choose one of the following options to run Azul Zulu Prime JVM:
Disable the hugepages facility on your Linux system when you are running Azul Zulu Prime JVM.
Ensure there is sufficient memory allocated to each: Azul Zulu Prime JVM, hugepages, and Linux memory.
Understanding Memory Allocation
The Azul Platform Prime uses the Azul Zulu Prime JVM to run Java applications in the same way that other JVMs run Java applications. The significant difference between the Azul Zulu Prime JVM and other JVMs is the management of memory. The Azul Zulu Prime JVM 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.
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 an Azul Zulu Prime JVM 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:
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 an Azul Zulu Prime 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 Azul Zulu Prime 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.