Visit Azul.com Support

Command-Line Options

Java command-line options that control the interaction between Azul Zing Builds of OpenJDK (Zing) and Azul Zing System Tools (ZST) begin with the -XX: prefix. These options summarized in the following table. Zing command-line options are case-sensitive.

Zing Command-Line Options

Command Line Option Description Default

-Xmx<size>[m|M|g|G]

Specifies the maximum size of the Java heap.

The Examples below both specify a 10 GB heap:

  • -Xmx10240M

  • -Xmx10G

Minimum and maximum heap sizes are as follows:

  • Minimum heap size for Xmx: 512 MB

  • Maximum heap size without ZST (x86): 2800 GB (2.8 TB)

  • Maximum heap size without ZST (ARM64): 5600 GB (5.6 TB)

  • Maximum heap size with ZST (x86): 20000 GB (20 TB)

Intel Ice Lake and newer x86 processors, when 5-level paging (LA57) is enabled at the OS level, can have a maximum heap size of 14000 GB (14 TB).

1 GB with ZST. 25% of the RAM size or cgroup/container limit, with a maximum value of 32 GB without ZST.

-Xms<size>[m|M|g|G]

Specifies the minimum size of the Java heap that is committed at the start of the Java command. During uptime, the Garbage Collector uses this minimum value as target heap utilization to minimize the memory footprint. For application environments with the primary goal of reducing latency and obtaining the highest throughput performance, setting -Xms to the value of -Xmx is recommended to avoid CPU intensive memory optimization.

When ZST is installed, this flag is ignored and the initial heap size is always set to the -Xmx value, except when heap elasticity is enabled. Heap elasticity is only available since 21.05.0.0. See Recommended Heap Size for details.

1.5625% of the RAM size or cgroup/container limit, with a minimum value of 128 MB and a maximum value of 2 GB.

-XX:MaxHeapSize=<size>[k|K|m|M|g|G]

Can be used instead of -Xmx<size>, see above.

-XX:InitialHeapSize=<size>[k|K|m|M|g|G]

Can be used instead of -Xms<size>, see above.

-XX:JavaMemMax=<size>[k|K|m|M|g|G]

Specifies the maximum amount of memory that can be allocated to the Zing process (the Java heap). Units can be specified in kilobytes (K or k), megabytes (M or m), or gigabytes (G or g). For example: -XX:JavaMemMax=2g -XX:JavaMemMax=128M -XX:JavaMemMax=128m If this option is not specified the maximum size to which Java heap can grow is calculated internally by the JVM based on the size of the Java system memory. Contact Azul customer support for more information about this option. You might need this option when multiple JVMs are run on the same host and frequent usage of contingency or pause prevention memory has been observed.

Value of -Xmx plus available Contingency Memory

-XX:InitialRAMPercentage=<value>

This is an alternative to -Xms and defines the initial heap size as percentage of the RAM of the machine, container or cgroup. With JDK 8, a decimal number is required as value, like 5.0. On JDK 11 and later integer numbers are also accepted. This parameter is only used when Heap Elasticity is enabled.

1.5

-XX:MaxRAMPercentage=<value>

This is an alternative to -Xmx and defines the maximum heap size as percentage of the RAM of the machine, container or cgroup. With JDK 8, a decimal number is required as value, like 75.0. On JDK 11 and later integer numbers are also accepted. The default value is 25.0, but the default is capped to a maximum of 32 GB.

25

-XX:[+/-]AutoTuneResourceDefaultsBasedOnXmx

Allows Zing to start with Xmx128M or Xmx256M by reducing default values for some parameters such as ReservedCodeCacheSize and GC thread count. The flag is automatically set to true for java -version, -help, etc.

true

-XX:[+/-]UseZST

Allows Zing to start with or without the Azul Zing System Tools (ZST) component.

false

-XX:NonZSTModePreferenceLevel=<value>

Sets the preference selection for launching Zing with ZST. The selection choices are as follows:

  • 0 - Never select the non-ZST mode. Zing will error out if ZST is not installed, configured, or enabled.

  • 1 - Select the non-ZST mode only if ZST is not installed properly.

    Note, if ZST is installed but misconfigured in this mode, Zing will error out.

  • 2 - Select the non-ZST mode if ZST is not installed, configured, or enabled.

    Note, when enabled, -XX:+UseZST overrides the -XX:NonZSTModePreferenceLevel command-line option with its value.

1

-XX:SelfDiagnosticRunPath=<directory>

and

-XX:SelfDiagnosticRunLevel=<value>

Since Azul Prime 22.02, you can enable multiple logs by using a master command line flag. This flag acts as an alias for a number of flags often used for logging, see "Master Monitoring Flag" for more details.

Level=2

-XX[+/-]UseTrueObjectsForUnsafe

Forces unsafe objects to be returned as their original class form, e.g. klassOop, instead of a Java class.

true

Master Monitoring Flag

The master monitoring flag can be used in two ways:

  1. Simple usage: add the target directory to the command line, and default level (= 2) will be used.

     
    -XX:SelfDiagnosticRunPath=<directory>
  2. Advanced usage: both directory and level are defined.

     
    -XX:SelfDiagnosticRunPath=<directory> -XX:SelfDiagnosticRunLevel=3

Diagnostic levels

There are three diagnostics levels. The 1st is the lowest with the smallest overhead; while the 3rd is the highest with the biggest overhead. These levels are additive, which means e.g. Level 2 equals to Level 1 flags + Level 2 flags, with possible overriding of some flags.

SelfDiagnosticRunLevel = 1

 
-XX:ProfileLogOut=<directory>/profileLogOut<timestamp>.profile -Xlog:gc,safepoint:<directory>/gc-log<timestamp>.log::filecount=5,filesize=50M -XX:SafepointWaitTimeProfilerLog=<directory>/safepoint-profile<timestamp>.log -XX:SafepointProfilerThresholdMS=5 -XX:+PrintCompilation -XX:+TraceDeoptimization -XX:-DisplayVMOutput -XX:LogFile=<directory>/hotspot<timestamp>.log -XX:+LogVMOutput

SelfDiagnosticRunLevel = 2

 
-XX:+FlightRecorder -XX:StartFlightRecording=filename=<directory>/jfr<timestamp>.jfr -Xlog:gc*,safepoint:<directory>/gc-log-<timestamp>.log::filecount=5,filesize=50M // OVERRIDDEN

SelfDiagnosticRunLevel = 3

 
-XX:FalconIRDumpRoot=<directory> -XX:FalconDumpIRToDiskOf=* -XX:+PrintInlining -Xlog:gc*,safepoint:<directory>/gc-log-<timestamp>.log::filecount=0 // OVERRIDDEN - ATTENTION: no limit to file size

Explanation of logging options

  • -XX:ProfileLogOut

    • Writes a ReadyNow profile.

  • -Xlog:gc,safepoint

    • Write the Azul Prime GC log including safepoints.

    • The GC log can be analysed using the GCLogAnalyzer tool found in <PRIME>/etc/GCLogAnalyzer2.jar`

    • With default settings (level 1 and 2) the log file size will be limited.

  • -XX:SafepointWaitTimeProfilerLog

    • Logs details on safepoint which take longer than normal the threshold is 5ms.

    • Under normal circumstances Safepoints should take less than 2ms and in a well configured system <500us.

    • -XX:SafepointProfilerThresholdMS=5

  • -XX:+PrintCompilation

    • Create a log of JIT compiler activity.

    • -XX:+TraceDeoptimization

      • Out of scope - please ask your Azul contact.

  • -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=<directory>/hotspot<timestamp>.log

    • Logs the compilation logs and other details to file.

  • -XX:+FlightRecorder

    • Enable Java Flight recorder logging with default settings.

    • -XX:StartFlightRecording=filename=<directory>/jfr<timestamp>.jfr

    • Java Flight Recorder logs can be opened with Azul Mission Control, a free tool for basic Java performance analysis.

  • -XX:FalconIRDumpRoot

    • Log the IR output of the Falcon JIT compiler.

    • The Falcon JIT in Azul Prime is based on the LLVM compiler project. LLVM uses an IR (Intermediate representation), a pseudo assembler, before compiling to binary. The IR is human-readable and can be analysed by our engineering team to gain insight into the optimizations made (or not made) by the JIT compiler.

    • -XX:FalconDumpIRToDiskOf=*

      • Log ALL classes.

    • -XX:+PrintInlining

      • Log extra detail for inlined methods.

Correctly Stopping Azul Prime While Logging

Please stop Prime gracefully (i.e., do not perform a hard kill -9 <pid>), to flush JFR (and other) buffers to a file. Otherwise, your JFR log will be empty (file size equals zero).

Intrinsic Options

Intrinsics are hand-tuned machine code integrated into the JVM for some numeric algorithms like BigInteger, AES encryption, CRC checksum calculations, and SSE/AVM opcodes. Most are turned on by default. To see a list of all adjustable intrinsic options of the current Zing JVM and their default values, run the following command:

 
/opt/zing/zing-jdk1.8.0-<version>/bin/java -XX:+PrintFlagsFinal -version 2>&1 | grep Intrinsic
Command-Line Option Description Default

-XX:[+/-]UseMultiplyToLenIntrinsic

Disables intrinsic for BigInteger::multiplyToLen()

true

-XX:[+/-]UseSquareToLenIntrinsic

Disables intrinsic for BigInteger::squareToLen()

true

-XX:[+/-]UseMulAddIntrinsic

Disables intrinsic for BigInteger::mulAdd()

true

-XX:[+/-]UseMontgomeryMultiplyIntrinsic

Implements BigInteger.montgomeryMultiply intrinsic.

true

-XX:[+/-]UseMontgomerySquareIntrinsic

Implements BigInteger.squareMultiply intrinsic.

true

-XX:[+/-]UseLog4jGetCallerClassIntrinsic

Enables intrinsic for log4j StackLocator.getCallerClass().

false

Prime Memory and CPU Footprint Control

You can use the VMFootprintLevel' flag to indicate the level of resources available in the environment where Azul Platform Prime runs. `VMFootprintLevel is a "master" option which results in tuning a number of internal options.

You can set VMFootprintLevel to "XL", "L", "M" or "S". "XL" is the default so there is no difference in behavior when you specify XL.

You can visit Analyzing and Tuning Warmup for more information on VMFootprintlevel and which settings are specifically changed using this option.

Native Memory Tracking Options

These options are useful to analyze usage of memory outside the Java heap and ZST memory for NIO, thread stacks.

Command-Line Option Description Default

-XX:[+/-]UseExtendedNMT

Enables or disables Extended NMT mode. Disabling this option tells Zing to run NMT in a Zulu-like mode.

true

-XX:[+/-]EnableNMTIntegrityChecks

Enables or disables checks on allocations.

true

-XX:[+/-]PrintNMTStatistics

Enables output of the Native Memory Tracking statistics.

false

-XX:NativeMemoryTracking=<tracking level>

Specifies the level of tracking output. Note that enabling this will cause 5-10% performance overhead.

  • off: Native Memory Tracking is turned off.

  • summary: Only collect memory usage aggregated by subsystem.

  • detail: Collect memory usage by individual call sites.

To extend the functionality in versions 23.02.0.0 through 23.05.0.0, it is necessary to use LD_PRELOAD. To enable this extended tracking, set the environment variable pointing to libnmt_hooks.so included in the Prime package. From version 23.06.0.0, the libnmt_hooks.so library is linked by default.

 
LD_PRELOAD=$JAVA_HOME/etc/zing/lib/libnmt_hooks.so

off

-XX:PrintNMTStatisticsRoot=<directory name>

Enables periodic NMT logging and specifies the directory where logs are periodically dumped. This is a diagnostic feature and requires -XX:+UnlockDiagnosticVMOptions.

null

-XX:PrintNMTStatisticsAtIntervalSec=<value in seconds>

Specifies the interval for printing the NMT logs to the specified directory.

10

Defensive Heap Shrinking

Defensive heap shrinking, introduced in Azul Platform Prime 24.02.0.0, dynamically reduces committed Java heap in order to avoid Out-of-memory (OOM) errors in container environments, which ordinarily lead to OOM kills and crashes.

Setting VMFootprintLevel to L, M or S enables UseDefensiveHeapShrinking with M and S setting DefensiveHeapShrinkingXmxSacrificePercent to 20 and L setting DefensiveHeapShrinkingXmxSacrificePercent to 10.

Command-Line Option Description Default

-XX:[+/-]UseDefensiveHeapShrinking

Enables defensive heap shrinking.

false

-XX:DefensiveHeapShrinkingXmxSacrificePercent=<percent>

The maximum amount by which you can lower the Java heap, as a percentage of Xmx.

5

-XX:DefensiveHeapShrinkingMaxNewGCDutyCyclePercent=<percent>

The maximum NewGC duty cycle, under which the heap is allowed to be reduced.

If NewGC duty cycle (time percentage) goes above this value, defensive heap shrinking isn’t applied.

75

-XX:DefensiveHeapShrinkingMinFreeBytes=<size in bytes>

The amount of free and available memory you want the machine to try to maintain in the container, as a percent of total Xmx.

3

Code Cache Use Optimization Options

Command-Line Option Description Default

-XX:[+/-]AllocCodeCacheInLower2G

Allocate code cache and related data structures at virtual address within 2 GB. The maximum supported code cache size while this option is disabled is 1758 MB.

true

-XX:[+/-]UseEmergencyCodeCacheFlushing

Disables emergency code cache flushing. Emergency flushing starts removing unused blobs only when more than 85% of code cache space is consumed. Before that it "sleeps" and does nothing. This option is enabled by default.

true

-XX:[+/-]UseIncrementalCodeCacheFlushing

Enables regular code cache flushing. Unlike emergency flushing, regular flushing triggers unused blobs removal during the whole lifetime of Zing, i.e., it never waits for reaching 85% of code cache utilization. This option can be helpful when the code cache memory is being exhausted despite UseEmergencyCodeCacheFlushing was enabled. This option is disabled by default.

false

-XX:[+/-]EnableC1Flushing

Turns off flushing of unused code blobs generated by the Tier 1 compiler. This option takes effect only if either the UseIncrementalCodeCacheFlushing or UseEmergencyCodeCacheFlushing option is set to true.

true

-XX:CodeCacheMinimumFreeSpace=<value in bytes>

Reserves the specified amount of space for code other than code compiled methods.

26845184

-XX:CodeCacheOopTableSize=<value in bytes>

Sets the initial size of the elastic table used internally by the VM to store information about object references that reside in the code cache. The maximum value is 64 MB.

25% of InitialCodeCacheSize

-XX:ReservedCodeCacheSize=<value in bytes>

Specifies the maximum size of the code cache. The minimum value is a minimum of 6% of Xmx and 256 MB. The maximum value is 4 GB.

10% of Xmx

-XX:InitialCodeCacheSize=<value in bytes>

Specifies the initial size of the code cache. The minimum value is a minimum of 3% of Xmx and 64 MB. The maximum value is the value of ReservedCodeCacheSize.

Minimum of 2% of Xmx and 10% of ReservedCodeCacheSize

-XX:[+/-]MlockCodeCache

Locks code cache in memory, preventing it from being paged out or swapped out. The option is not applicable to the ZST mode.

true for non-ZST mode

-XX:[+/-]AllocCodeCacheInCHeap

Decides whether code cache is accounted under C heap or under Java heap.

true for non-ZST mode false for ZST mode

Monitor Cache Use Optimization Options

Command-Line Option Description Default

-XX:InitialMonitorCacheSize=<value>[K|M|G]

Specifies the initial size of the monitor cache. Units can be specified in kilobytes (K or k), megabytes (M or m), or gigabytes (G or g).

0

-XX:ReservedMonitorCacheSize=<value>[K|M|G]

Specifies the maximum size of the monitor cache. Units can be specified in kilobytes (K or k), megabytes (M or m), or gigabytes (G or g).

512M

-XX:[+/-]AllocMonitorCacheInCHeap

Allows choosing between C heap and Java heap memory for MonitorCache. Using monitor cache elasticity is not recommended when monitors are in Java heap and, by default, InitialCodeCacheSize is set to ReservedCodeCacheSize when the flag is disabled.

true

-XX:[+/-]MlockMonitorCache

Locks memory (mlock) to prevent monitor cache pages from being swapped out.

true

Thread Local Allocation Buffer (TLAB) Use Optimization Options

Command-Line Option Description Default

-XX:MinTLABSize=<value in bytes>

Minimum allowed size of the thread local allocation buffer (in bytes).

32768

-XX:[+/-]GPGCUseFullPageTLABs

When true, uses a single 2 MB page as a fixed size TLAB.

true

-XX:TLABRefillWasteFraction

Specifies maximum TLAB waste at a refill (internal fragmentation).

16

-XX:TLABSize=<value in bytes>

Sets the size of the thread local allocation buffer.

2031616

-XX:TLABResizeStepPercent

25

-XX:TLABWasteTargetPercent

Determines the percentage of the threshold of the TLAB when the object size is larger than a threshold, the TLAB is retired, and the object is allocated inside a new TLAB.

25

Zing in the Non-ZST Mode Options (available since Azul Zing 19.06.0.0)

Command-Line Option Description Default

-XX:[+/-]UseLargePages

Enables Zing to use large (2M pages) if the system is properly configured. Before trying to use large pages, read Using Huge Pages with Zing for system configuration steps.

true for Zing with ZST, false for Zing in non-ZST mode

-XX:[+/-]UseTransparentHugePages

Enables Zing to use Transparent Huge Pages (THP) in shared memory madvise mode if the system is properly configured. Before trying to use large pages, read Using Huge Pages with Zing for system configuration steps. To enable, use -XX:-UseTransparentHugePages. Transparent Huge Pages (THP) in shared memory madvise mode is available in Linux kernel version 4.12.10 and above.

false

-XX:[+/-]UseTransparentHugePagesForCodeCache

Use Transparent Huge Pages (THP) for code cache provided that (a) it is allocated in C heap memory and (b) it is safe to use THP without incurring defragmentation stall.

true

-XX:[+/-]UseTransparentHugePagesForMonitorCache

Use Transparent Huge Pages (THP) for monitor cache provided that (a) it is allocated in C heap memory and (b) it is safe to use THP without incurring defragmentation stall.

true

-XX:[+/-]UseTransparentHugePagesForSideBand

Use Transparent Huge Pages (THP) for sideband forwarding table provided that (a) it is allocated in C heap memory and (b) it is safe to use THP without incurring defragmentation stall.

true

-XX:[+/-]ThpDisable

Used to explicitly disable Transparent Huge Pages, overriding the parent process / system default

false (inherited from parent process)

-XX:GPGCNoZSTBackingStoragePath=<path>

Points to the mount point for managing large pages when configuring static Large pages. Used in conjunction with -XX:UseLargePages on Linux kernel versions prior to 4.14. Before trying to use large pages, read Using Huge Pages with Zing for system configuration steps.

-XX:[+/-]GPGCNoZSTUseNUMAInterleaving

Enables non-uniform memory access (NUMA) interleaving when libnuma library is present.

false if either libnuma (API version 2) is not present on the system or if the process has been already memory-bound to specified nodes using the numactl —membind option; true otherwise.

-XX:[+/-]GPGCNoZSTWorkaroundRSSInaccuracy

Report more accurate resident set size (RSS) value for off heap memory in the GC log file. In the non-ZST mode, Zing uses the shared memory multimapping facility provided by Linux. However, the RSS reported by Linux is known to be inaccurate when the process does multimapping. When the flag is turned on, Zing tries to compute a more accurate value for RSS, which is then reported in the GC log.

false

-XX:[+/-]AlwaysPreTouch

Acquires all of Xmx upfront before starting the application. If the option is not specified, a JVM internal thread acquires the memory in the background after an application is started.

false

-XX:[+/-]GPGCNoZSTUseOptimizedMlockAll

Optimizes mlockall(2) behavior to significantly reduce application exit times.

true

Garbage Collector Options

Command-Line Option Description Default

-XX:[+/-]GPGCCommitInitialHeapLazily

Prevents the whole of the initial heap size, InitialHeapSize or -Xms, from being committed from the OS upfront, according to the specified value of GPGCLazyInitialHeapCommitPercent. The remainder gets committed based on regular elastic heap heuristics.

false

-XX:GPGCLazyInitialHeapCommitPercent

Specifies what percent of InitialHeapSize or -Xms shall be committed from the OS upfront at startup, when GPGPCCommitInitialHeapLazily is enabled.

50

-XX:[+/-]GPGCReportLegacyGarbageCollectorMXBean

Java 11 and 17: Switches back to the previous MXBean GC metric name java.lang.GarbageCollector.GPGC New and java.lang.GarbageCollector.GPGC Old.

true

-XX:[+/-]GPGCUseAllocationPacing

Allows VM to smoothly decrease allocation rate of the application if GC doesn’t keep up. Helps to avoid complete exhaustion of heap space followed by possibly long stalls. Available in non-ZST mode only.

false

-XX:[+/-]CheckpointTimeout

Tells the JVM to promote a checkpoint to a safepoint if the checkpoint takes too much time. A checkpoint happens when the JVM needs to interrupt a single Java thread and do something to it. The action will not affect any other threads that are running.

true

-XX:[+/-]DieOnSafepointTimeout

Abort the VM upon failure to reach safepoint. A safepoint happens when the JVM needs to pause every Java thread that’s running in order to perform an operation which can only happen when all threads are asleep

true

-XX:CheckpointTimeoutDelay=<value in ms>

Delay in milliseconds for option CheckpointTimeout.

50000

-XX:SafepointTimeoutDelay=<value in ms>

Delay in milliseconds for option DieOnSafepointTimeout.

50000

-XX:[+/-]DieOnSafepointOperationTimeout

Abort the VM if safepoint operationTime exceeds SafepointOperationTimeoutDelayMS.

false

-XX:SafepointOperationTimeoutDelayMS=<value in ms>

Timeout, in milliseconds, for safepoint operation when DieOnSafepointOperationTimeout is enabled.

50000

-XX:GPGCActiveObjectPaddingSize=<number>

Number of cache lines of padding to insert after mutator relocated objects during relocation.

0

-XX:[+/-]GPGCRetainActiveObjectPadding

When true, retain any previously allocated active object padding during GC relocation. When false, any previously allocated active object padding is removed during GC relocation and will not be re-added until the object is mutator relocated again.

false

-XX:GPGCTimeStampPromotionThresholdMS=<value in ms>

Time, in milliseconds, that an object page stays in the new generation before getting promoted to the old generation.

2000 for Xmx > 2 GB, 500 for Xmx ⇐ 2 GB

-XX:GPGCNewGenConcurrentMarkFlushRetryLimit=<upper limit of retries>

Limits the number of mutator NMT reference buffer flushes performed during concurrent marking. The default value of the retry limit is 3. To return to the old behavior of looping in concurrent marking until no more mutator references are flushed, change the default value to -1.

3

-XX:GPGCNewGenConcurrentMarkFlushRetryLimitAction=<upper limit of iterations>

Controls the behavior of the new garbage collector when the number of iterations of the concurrent marking mutator NMT flush loop exceeds the specified retry limit. The default action is to perform reference strengthening followed by iterating the limit of retries more times before exiting out of the loop and heading toward the safepoint.

2

-XX:GPGCPausePreventionMemory=<value in bytes>

Allocates the limit from the pause fund to restrict pause prevention memory.

-1

-XX:GPGCHeuristicCheckIntervalMS=<time interval in ms>

Controls the time interval between consecutive heuristic evaluations when Zing runs heuristics to determine the time to trigger a garbage collection. The default is 20 milliseconds starting with Zing 20.03.0.0. Before Zing 20.03.0.0, it was 50 milliseconds.

20

-XX:[+/-]UseEpsilonGC

Implements a no-op garbage collector. When enabled, Zing neither triggers any GC cycles nor generates GC barriers. Being an experimental option, it needs to be unlocked by preceding -XX:+UnlockExperimentalVMOptions.

false

-XX:GPGCHeuristicHalfLifeMS=<value in ms>

Specifies the half-life, in milliseconds, for exponential decay of heuristic models that drive triggering of garbage collection cycles.

60000

-XX:GPGCNewGCMaxIntervalMS=<value in ms>

Specifies the maximum interval between new generation garbage collection cycles triggered by GC heuristics. The interval is calculated from the start of the previous new generation collection.

0

-XX:GPGCOldGCMaxIntervalMS=<value in ms>

Specifies the maximum interval between old generation garbage collection cycles triggered by GC heuristics. The interval is calculated from the start of the previous old generation collection.

0

-XX:GPGCMaxOldGCInterval=<number>

Specifies the maximum number of new GC cycles that can be run before triggering the next full (Old) GC cycle.

-1

-XX:[+/-]UseGCUnifiedLogging

Enables unified GC logging in Zing 8, 11, and 13.

true

-XX:GPGCTargetPeakNewGenOccupancyBytes=<value in bytes>

Specifies the soft limit for java heap usage by the new generation, in bytes, that GC heuristics target to achieve.

If GPGCTargetPeakNewGenOccupancyBytes is not set, the value will be adjusted dynamically. Explicitly setting this option disables dynamic allocation.

0

-XX:GPGCTargetPeakNewGenOccupancyPercent=<value>

Specifies the soft limit for java heap usage by the new generation, as a percentage of the maximum heap size, that GC heuristics target to achieve.

If GPGCTargetPeakNewGenOccupancyPercent is not set, the value will be adjusted dynamically. Explicitly setting this option disables dynamic allocation.

0

-XX:GPGCTargetPeakHeapOccupancyPercent=<value>

Specifies the soft limit for overall java heap usage, as a percentage of the maximum heap size, that GC heuristics target to achieve.

If GPGCTargetPeakHeapOccupancyPercent is not set, the value will be adjusted dynamically. Explicitly setting this option disables dynamic allocation.

100 for ZST reserve-at-config, 95 for ZST reserve-at-launch, 90 for non-ZST mode

-XX:GenPauselessNewThreads=<value>

Specifies the number of garbage collection worker threads for the new generation. Setting default value is based off of Xmx: If Xmx is more than 2 GB, the default value is 45% of the number of logical cores available to the process. If Xmx is less than or equal to 2 GB, the default value is either Xmx divided by 128 MB or 45% of the number of logical cores available to the process, whichever is smaller. If -XX:+UseSTW is specified, the default value is the number of logical cores. available to the process.

The minimum value supported is 1.

If not set, this value can be managed dynamically. See note in -XX:GPGCThreads.

15

-XX:GenPauselessOldThreads=<value>

Specifies the number of garbage collection worker threads for the old generation. Setting default value is based off of Xmx:

  • If Xmx is more than 2 GB, the default value is 30% of the number of logical cores available to the process.

  • If Xmx is less than or equal to 2 GB, the default value is either 66% (two thirds) of the value of GenPauselessNewThreads, or 30% of the number of logical cores available to the process, whichever is smaller.

  • When -XX:+UseSTW is specified, the default value is the same as the number of logical cores available to the process.

The minimum value supported is 1.

If not set, this value can be managed dynamically using . See note in -XX:GPGCThreads.

9

-XX:GPGCThreads=<value>

Specifies the total number of garbage collection worker threads This is an alternative way to specify GenPauselessNewThreads and GenPauselessOldThreads When used, GenPauselessOldThreads is derived as 40% of GPGCThreads. GenPauselessNewThreads is then derived as GPGCThreadsGenPauselessOldThreads. The default value is the sum of the default values of GenPauselessNewThreads and GenPauselessOldThreads.

The minimum value supported is 2.

Note
As of Azul Platform Prime 21.10.0.0, if the values GPGCThreads, GenPauslessNewThreads, and GenPauselessOldThreads are not set, the number of garbage collector worker threads are managed dynamically using UseDynamicNumberOfGCThreads, if enabled, according to the configuration of GPGCDynamicGCThreadCountPolicy.

24

-XX:[+/-]UseDynamicNumberOfGCThreads

Turn on/off dynamic changes to GC thread counts.

true

-XX:GPGCDynamicGCThreadCountPolicy=<value>

Enable dynamic garbage collection thread count policy.

  • 0 - Disable dynamic handling. Set a static garbage collector thread count that is fixed to the -XX:GPGCThreads value.

  • 1 - The garbage collector thread count is managed automatically and will dynamically increase but never decrease. The thread count is limited by -XX:GPGCThreads=N.

  • 2 - The garbage collector thread count is managed automatically and will be increased and decreased dynamically. The thread count is limited by -XX:GPGCThreads=N.

1

-XX:[+/-]ConcurrentJVMTITagMapClearing

Lower GC pauses with JVMTI, resolving deadlock with callbacks during JVMTI tag map clearing

true

-XX:[+/-]GPGCNotifyJVMTIGCEventsInSafepoint

When enabled, the JVM issues JVMTI GC event notifications from within safepoints. Disabling it causes notifications to happen from outside the safepoint.

true

-XX:[+/-]GPGCUseTargetCPUHeuristic

If disabled, will cause CPU-based heuristics to be skipped for heap elasticity and dynamic GC thread counts.

true

-XX:[+/-]GPGCSafepointWaitForMutatorResume

Tells the Garbage Collector to pause and wait for mutator threads to be woken up before resuming, after every GC safepoint. If -XX:-GPGCSafepointWaitForMutatorResume is set, the Garbage Collector resumes its work in parallel with mutator threads waking up.

true

-XX:PrintGCHeadersGuaranteedIntervalSecs=<value in seconds>

When set to a value greater than zero, defines a time interval for periodic printing of GC log headers. This helps open partial GC logs in GC log analyzer, for example those pulled from Splunk.

0

Per-thread CPU utilization in GC Log

Available from Azul Platform Prime 23.06.0.0, the per-thread CPU utilization options allow collection and charting of per-thread CPU core statistics.

Command-Line Option Description Default

-XX:[+/-]PrintCPUUtilization

Enable printing of CPU utilization for process threads in JDK8-style logging.

false

-Xlog:gc,cpuut:<filename>

Enable printing of CPU utilization for process threads in unified logging.

-

-XX:PrintCPUUtilizationAtIntervalSec=<time in seconds>

Interval in seconds, at which CPU utilization statistics will be printed to GC log. Once printed the counters are reset to zero.

20

-XX:ThreadCPUUtilizationReportThreshold=<number of cores>

Threshold, in cores, below which a thread will be grouped under OTHER category for reporting rather than being logged separately.

0.04

-XX:PrintCPUUtilizationCollectMode=<string>

Mode of data sampling. Accepted strings are "snapshotAtIPrintInterval" and "averageOverPrintInterval".

  • snapShotAtPrintInterval: Two samples will be taken around the print interval and the average will be computed between them (similar to what "top -H" does).

  • averageOverPrintInterval: The averaging is done across the entire print interval.

snapshotAtIPrintInterval

-XX:CollectCPUUtilizationAtIntervalMillis=<time in milliseconds>

Interval between the two samples in "snapshotAtPrintInterval" mode.

150

-XX:+CollectSystemwideCPUUtilization

Enable collection of CPU utilization for each thread on the system.

false

Garbage Collector Options to Control ZVision Output

Note
As of Azul Platform Prime 23.08.0.0, ZVision and ZVRobot components have been deprecated and are no longer actively developed. While we still support these components, we encourage users to switch to Java Flight Recorder(https://docs.azul.com/prime/Java-Flight-Recorder), as ZVision and ZVRobot are planned for End-of-life with Azul Platform Prime 24.02.0.0 (February 2024).

These Zing command-line options control the output of garbage collector information when using ZVision.

Command-Line Option Description

-Xloggc:[filename]

Enables verbose GC logging and directs it to a file. It is recommended to add a timestamp and a PID to get a unique log name:

-Xloggc:gc_%t_%p.log

-XX:[+/-]PrintGCDetails

Enables the detailed logging output.

-XX:PrintSYSINFOAtIntervalSec=<value in seconds>

Writes the SYSINFO line (CPU load, memory usage, paging info) at fixed intervals in seconds.

As of Zing release 5.10.0, the default value of the Zing flag DisableExplicitGC is off. Prior to release 5.10.0, calls to System.gc() were ignored and no garbage collection was initiated unless -XX:-DisableExplicitGC was set. From 5.10.0 this is no longer the case and System.gc() calls may initiate a full GC cycle depending on the value of the GPGCOptimisticExplicitGC flag. If a System.gc() call initiates a garbage collection, the calling thread may or may not be blocked for the duration of the GC depending on the value of the SynchronousExplicitGC flag. The previous behavior is achieved by turning on the DisableExplicitGC flag, using -XX:+DisableExplicitGC.

  • -XX:[+/-]GPGCOptimisticExplicitGC

    When enabled, a thread calling System.gc() initiates a new garbage collection if and only if one is not already in progress or one is pending. This flag is enabled by default.

  • -XX::[+/-]SynchronousExplicitGC

    When enabled, a thread that initiates a garbage collection by calling System.gc() is blocked for the entire garbage collection cycle and resumes when the GC completes. Otherwise, a concurrent garbage collection is initiated and the calling thread continues to execute. This flag is enabled by default.

Advanced Miscellaneous Options

Command-Line Option Description Default

-XX:[+/-]OptimizeFindDeadlocksWithCheckpoint

Enable elimination of safepoint pauses for finding deadlocks operations by first attempting to complete them using a checkpoint. If a deadlock is detected in the checkpoint, it is then confirmed using a safepoint pause.

true

-XX:DiagnosticFolder=<path>

Gathers all useful diagnostic logs into one folder for easier evaluation.

none

-XX:[+/-]PrintGCHSLines

Enables writing system information headers (GCHS) in the garbage collection log file.

true if GC logging is enabled, false if GC logging is disabled

-XX:[+/-]PrintGCExtraDetails

Enables a new Garbage Collector logging level used wherever the data collection or reporting has a noticeable overhead. This flag also enables PrintGCDetails which is the next lower logging level.

false

-XX:[+/-]PromoteCheckpoints

Lets tardy threads complete the checkpoint process by pausing active threads. See Troubleshooting Guide for suggestions on when to use this option.

false

-XX:CheckpointPromotionDelay=<time in ms>

Defines the threshold for triggering the promotion timeout. This flag has an effect when -XX:+PromoteCheckpoints is specified.

850

-XX:ProfileStartupLimitInSeconds=<value in seconds>

Sets time limit for ReadyNow to wait for compilations to finish at startup as specified in seconds. For infinite, use -1.

0

-XX:ActiveProcessorCount=<number of CPUs>

Allows for specifying explicitly the number of CPUs available for Zing. Works only with the container support (i.e., if -XX:-UseContainerSupport is not specified) and overrides the automatic CPU detection logic in the JVM.

-1

-XX:[+/-]UseContainerSupport

Turns off using container-specific information about available CPUs instead of using the information about the whole system. Enabled by default.

true

-XX:[+/-]DashVersionSilenceLicenseErrors

Starting with Zing 18.07.0.0, Zing diagnoses licensing problems if run with -version option: it prints a warning and exits with an error code. If this option is specified together with -version, the JVM ignores licensing problems (specifically the warning is not printed) and exits with 0. Setting the ZING_DASH_VERSION_SILENCE_LICENSE_ERRORS environment variable has the same effect.

false

-XX:[+/-]PreserveFramePointer

(Available since Zing 17.03.0.0; requires ZST 5.18.0 or later) The flag is needed for producing flame graphs with the Linux perf utility and for similar performance analysis tools which rely on stackwalking to record Java method invocations, the time percentage spent in them, and their use of Linux system function calls.

false

-XX:[+/-]UseLLVMBasedDisassembler

Turns the LLVM-based disassembler off. Starting with Zing 18.07.0.0, the default disassembler is changed from Zing internal to LLVM-based.

true

-XX:PrintAssemblyOptions=intel <diagnostic>

Changes disassembly syntax from AT&T to intel. This flag is diagnostic and must be preceded by -XX:+UnlockDiagnosticVMOptions.

-XX:[+/-]UseModifiedThreadLocal

Internally polls on a ReferenceQueue to determine if a key object has been garbage collected rather than polling by checking for NULL through the Reference.get() API, that can unintentionally prevent the weakly reachable key from being garbage collected. The flag is more friendly to garbage collectors that perform marking concurrently.

true

-XX:[+/-]UseSpecialArrayCopy

Indicates which version of arraycopy of objects intrinsic works with. When set to true, it stands for a new vectorized intrinsic version. When set to false, it stands for the old scalar version.

true

-Xnativevmflags:[ignore|error|warn]

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’

If -Xnativevmflags:warn is specified as a last option in the command line, it enables a warning message for each OpenJDK JVM option ignored by Zing. It prints a warning message while your application starts normally, for example:

$ /opt/zing/zing-jdk8/bin/java -XX:+UseParallelGC -Xnativevmflags:warn -version

Zing 64-Bit Tiered VM warning: Ignoring unsupported native VM option '+UseParallelGC'

java version "1.8.0-zing_18.12.0.0"

Zing Runtime Environment for Java Applications (build 1.8.0-zing_18.12.0.0-b4)

Zing 64-Bit Tiered VM (build 1.8.0-zing_18.12.0.0-b9-product-azlinuxM-X86_64, mixed mode)

ignore

-XX:[+/-]ResetSignalMaskAtLaunch

Clears the signal mask to enable SIGQUITs when set to true.

true

-XX:ProfilePreMainTier2ExtraCompilerThreads=<number of threads>

Enables the use of extra threads for compilations for C2 and Falcon during the pre-main phase when ReadyNow triggers and executes different activities.

This option is complementary to CIMaxCompilerThreads.

In pre-main phase when your code is not yet being executed and GC is silent, the total amount of C2/Falcon compiler threads is equal to the sum of CIMaxCompilerThreads and ProfilePreMainTier2ExtraCompilerThreads. Note that the sum is capped to match the number of CPUs available for Zing on a machine.

When the pre-main phase is done (i.e., ProfileStartupLimitInSeconds is exhausted) and your main is started, the total amount of compiler thread goes back to standard CIMaxCompilerThreads.

2

-XX:ProfileWorkerThreads=<number of threads>

When this option value is greater than 0, it allows ReadyNow to use multiple concurrent background threads to asynchronously trigger and execute different ReadyNow-related activities such as early class loading, class initializations, or trigger compilations.When the flag value is set to 0, old synchronous event’s triggering and/or processing is used.

The default value is equal to the minimum number of CPUs available for Zing on a machine.

4

-XX:[+/-]RunVMErrorOnUnhandledSignals

Does error reporting for SIGABRT, SIGFPE, and SIGTRAP signals if there are no user defined handlers installed.

true

-XX:[+/-]SafelyTrustEffectivelyFinalFields

Enables effectively final optimizations for private fields which are initialized inside a constructor or class initializer, but are otherwise read only. The effectively final family of optimizations allows the VM to perform compiler optimization as if the fields were constants, but deoptimize if a later write is detected at runtime.

true

-XX:[+/-]UseOpenJSSE

Enables the OpenJSSE provider that supports TLS 1.3, see https://github.com/openjsse/openjsse for details.

false

-XX:[+/-]UseLegacy8uJSSE

Enables the Legacy8uJSSE provider that includes the 8u252 JSSE provider implementation without TLS 1.3 support as a fallback measure, and the non-default OpenJSSE provider previously included in Zing 8 distributions for non-default support for TLS 1.3. See Using Version 1.3 of Transport Layer Security (TLS) Protocol for details.

false

-XX:MaxRAMPercentage=<percentage of the memory limit>

Adjusts the maximum heap size (if not explicitly specified) based on the configured cgroup memory limit. If Xmx is not specified, the VM heap size limit is calculated as (MaxRAMPercentage / 100) * cgroups_limit.

25

-XX:[+/-]AlignArrayStart

Enables 64-bit alignment of the starting point of any array in the heap memory.

true

-XX:HserrRawCodeWindowSize=<size in bytes>

Specifies the size of raw x86 instructions to dump into hs_err file.

512

-XX:MlockLevel=<level>

Selects the memory locking strategy during JVM initialization:

  • 0 - Do not attempt any mlock in the JVM.

  • 1 - Lock only libjvm.so text region (can mlock up to 20 MB).

  • 2 - Lock all existing memory regions before JVM initialization (can mlock up to 150MB).

  • 3 - Lock all existing memory regions at the end of JVM initialization (can mlock up to 500 MB with ZST mode, additionally locks the complete Xmx with non-ZST mode).

Note that for the mlock operation to succeed the user should have permission to lock the required amount of memory in RAM. Check the ulimit l setting before starting the JVM with the MlockLevel option. Only a privileged user can increase this limit.

By default, no error message is printed if the mlock operation fails. Adding 1000 to the values above results in the same operation performed with errors, if any, printed to stderr. For example, specifying -XX:MlockLevel=1001 will print a warning if locking libjvm.so text region fails but -XX:MlockLevel=1 will not.

1

-XX:[+/-]KeepCodeEntrantOnAsyncExceptions

Keeps code of the compiled method entrant for further utilization (instead of making it non-entrant) in the case when an asynchronous exception (OutOfMemoryError, StackOverflowError) occurs during the execution of the JIT-compiled version of the method.

false

-XX:[+/-]ProfileExitOnInputError

Exits when an input profile is specified but cannot be found or is malformed. The option is applicable when file_name is missing for -XX:ProfileLogIn=<filename>.

false

-XX:[+/-]UseFastJNIAccessors

Enables JNI Get<type>Field function optimization. When the optimization is enabled, the function tries to quickly access the field value first. If it is not possible (e.g., garbage collection is in progress), the value is retrieved with the standard procedure.

true

-XX:[+/-]UseSpecialHashSet

Enables optimization for a special HashSet filling pattern when elements of the input collection are frequently added into an empty HashSet.

false

-XX:[+/-]UseThreadStateNativeWrapperProtocol

Enables lock-less JNI transitions.

This flag needs a minimum of 4K available lockable memory to be enabled. Otherwise, the flag ergonomically resets to false.

true

-XX:[+/-]UseKestrelC2

Enables a newer C2 implementation introduced to Zing in 2020. It is based on a lightweight use of the LLVM backend, and typically produces faster code than UseSeaOfNodesC2 while keeping compilation effort at similar levels. UseKestrelC2 generally exhibits a significantly lower compilation-time CPU consumption compared to Falcon.

This option is complementary to UseC2.

true

-XX:[+/-]UseSeaOfNodesC2

Note
Deprecated since 24.02.0.0

Enables the traditional C2 implementation that has been part of Zing since 2010.

This option is complementary to UseC2.

false

-XX:ZingTestingGracePeriodSec=<value in seconds>

Specifies the Zing testing grace period, in seconds (up to 3600).

0

-XX:[+/-]UseFastJNIExceptionCheck

Enables the JNI ExceptionCheck function optimization. When the optimization is enabled, the function tries to quickly check for a synchronous pending exception. If an async exception is set, the exception check happens with the standard procedure.

true

-XX:[+/-]MaxFDLimit

Enables the attempt to set the soft limit for the number of open file descriptors to the hard limit.

true

-XX:[+/-]UseLegacyJNINameEscaping

Enables skipping the extra mapping check to avoid compatibility issues due to new mapping rules for JNI methods introduced in JDK-8233624. See New mapping rules from a Java native method name to a C native library implementation function name for more information about new mapping rules.

false

-XX:[+/-]GPGCReportJavaHeapPoolMXBean

Exposes the total sum of memory usage of all MemoryPoolMXBean memory pools to the java.lang.management interface.

false

-XX:GPGCHeapJavaPoolMXBeanName=<value>

Specifies the name of the total java heap pool only when GPGCShowJavaHeapPoolMXBean is enabled.

0

-XX:GPGCNewGenPoolMXBeanName=<value>

Specifies the name of the new generation in the java heap pool.

0

-XX:GPGCOldGenPoolMXBeanName=<value>

Specifies the name of the old generation in the java heap pool.

0

-XX:GPGCPermGenPoolMXBeanName=<value>

Specifies the name of the permanent generation in the java heap pool.

0

-XX:[+/-]UseModifiedRuleBasedCollator

Enable the use of the custom implementation of RuleBasedCollator to improve performance over OpenJDK’s text collation and normalization.

true

-XX:[+/-]UseModifiedInputStreams

Use unsynchronized ByteArrayInputStream if it is used as an input of ObjectInputStream as a custom implementation.

false

-XX:[+/-]UseContainerCpuShares

Consider CPU shares when computing available processors inside a cgroup.

false

-XX:[+/-]PreferContainerQuotaForVMInternalCPUCount

Use CPU quota divided by period as base for calculating VM internal thread counts in containers.

true from Azul Platform Prime 23.08.0.0.

-XX:[+/-]PreferContainerSharesForVMInternalCPUCount

Use CPU shares divided by 1024 as base for calculating VM internal thread counts in containers.

false

-XX:MallocArenaMax=<number of memory pools>

Defines the maximum number of memory pools available for glibc.

0

-XX:[+/-]OptimizeIdentityHashForDistribution

Enables an alternate implementation for System.identityHashCode() which provides better distribution of objects at the cost of making the identity hash calculation itself slower.

enable

Reserved Memory Command

When a Java application starts, heap memory is Reserved according to the value specified using the -Xmx command-line option. If not specified, the value is 1 GB.

There is no specific ulimit pertaining to -Xmx for Zing. Such memory is configured for use during the system’s configuration using ZST. Configuration of the system using ZST requires root level permissions (superuser).

If -Xmx is less than 1 GB, Zing automatically increases it to 1 GB and writes a warning to stderr.

If you are running on a SUSE Linux Enterprise Server (SLES) system, prior to launching Zing for the first time, set the amount of virtual memory available to the shell using ulimit. At the command line, type:

ulimit -v unlimited

Collecting JVM Behavior Data by Using jstat

To collect information about Zing’s garbage collectors' behavior, use Zing’s monitoring tool (jstat) with the -gpgc command-line option . Use the jstat distributed with Zing, not the jstat distributed with Oracle’s JVM.

Usage Syntax

 
jstat -gpgc [-t == show timestamps] pid [msec between samples [# samples]]

Samples

Sample -gpgc, -t, samples, #samples options

 
$ jstat -gpgc -t 6549 10 5 Timestamp NGU OGU PGU JHMX NGC NGCT OGC OGCT GCT 172.0 419840.0 2048.0 6144.0 1036288.0 276 170.689 123 94.579 265.268 172.1 419840.0 2048.0 6144.0 1036288.0 276 170.689 123 94.579 265.268 172.1 419840.0 2048.0 6144.0 1036288.0 276 170.689 123 94.579 265.268 172.1 419840.0 2048.0 6144.0 1036288.0 276 170.689 123 94.579 265.268 172.1 419840.0 2048.0 6144.0 1036288.0 276 170.689 123 94.579 265.268

Sample -gpgc option

 
$ jstat -gpgc 44265 NGU OGU PGU JHMX NGC NGCT OGC OGCT GCT 36864.0 73728.0 36864.0 1036288.0 742 186.860 221 147.621 334.481

Sample -class option

 
$ jstat -class 44265 Loaded Bytes Unloaded Bytes Time 3063 7777.3 1 0.0 1.14

Sample -gc option

 
$ jstat -gc 44265 NGU OGU PGU JHMX NGC NGCT OGC OGCT GCT 36864.0 73728.0 36864.0 1036288.0 742 186.860 221 147.621 334.481

Sample -gccause option

 
$ jstat -gccause 44265 JavaHeapPercentUsed NGU OGU PGU JHMX NGC NGCT OGC OGCT LGCC GCC 14.23 36864.0 73728.0 36864.0 1036288.0 742 186.860 221 147.621 No GC No GC

Sample -gcnew option

 
$ jstat -gcnew 44265 NGU JHMX NGC OGC NGCT 36864.0 1036288.0 742 221 186.860

Sample -gcold option

 
$ jstat -gcold 44265 PGU OGU JHMX NGC OGC OGCT GCT 36864.0 73728.0 1036288.0 742 221 147.621 334.481

Sample -gcutil option

 
$ jstat -gcutil 44265 JavaHeapPercentUsed JHMX NGC NGCT OGC OGCT GCT 14.23 1036288.0 742 186.860 221 147.621 334.481

Sample -stats option

 
$ jstat -stats 44265 Loaded classInitTime classLinkedTime classVerifyTime sun.cls.time applicationTime safepointSyncTime safepointTime vmOperationTime NGC NGCT OGC OGCT 3063 0.759357 0.121911 0.250850 1.140906 1996.780026 0.450701 1.511731 1.663066 742 186.860000 221 147.621000

Sample -profile option

 
$ jstat -profile 44265 Loaders IDedLoaders Class SpecLoad SpecInit Loaded Inited Developed Method T1E T1C T2E T2C Profiled ProfUsed Warn Error 21 2 3065 2947 1697 2927 2274 1445 1407 230 220 221 831 797 261 0

Sample -profileerrors option

 
$ jstat -profile 44265 Warn ColClass SpecLoadFail UnmatchLoad RepLoad OverDeveloped Error ColLoader UnresLoaders UnresClass SpecInitFail UnresMthod ColMathod 18 1 0 15 0 2 0 0 0 0 0 0 0

Sample -deopt option

 
$ jstat -deopt 44265 CHA UnreachedIf UnreachedCall Unloaded Uninit Unexpected Null StuckInLoop NotEntrant Cast Range Throw Div0 UncountedLoops Jvmti Other 13 6 13 0 0 2 1 0 0 3 0 0 0 0 0 0

See also Using jstat with ReadyNow Profile.

Output Header Descriptions

Header Description

applicationTime

Time called

Bytes

Bytes consumed

classInitTime

Time called

classLinkedTime

Time called

classVerifyTime

Time called

GCC

GC cause

GCT

Both generation collectors total GC time

JavaHeapPercentUsed

Percent of memory used by Java heap

JHMX

Java heap Xmx value

Loaded

Processes loaded

LGCC

Last GC cause

NGC

New generation GC count

NGCT

New generation GC time (concurrent time the collector is running)

OGC

Old generation GC count (at that instant)

OGCT

Old generation GC time (concurrent time the collector is running)

NGU

New generation use (at that instant)

OGU

Old generation use (at that instant)

PGU

Permanent generation use

safepointSyncTime

Time called

safepointTime

Time called

sun.cls.time

Time called

Time

Elapsed time

Unloaded

Processes unloaded

vmOperationTime

Time called

Zing Mini-Core File Option

There is an option, -XX:+DumpMiniCore, that creates significantly smaller Zing core files. This option is specified through the Java application launch command and applied to the runtime Java application. It is not applied to the Zing host machine. When you use this option:

  • Generated Zing core files do not include application objects stored in the Java heap.

  • Time required to produce a Zing core file or core file bundle is reduced.

Zing Mini-Core File Requirements

The mini-core file option requires ZST 5.7.5 or later and Zing 5.10.x or later.

If the option is specified and either the ZST version or Zing version is not compatible, a message is issued.

  • If the ZST version supports the -XX:+DumpMiniCore option, but the Zing version does not, an Unrecognized VM option warning is printed to STDERR. For example:

     
    $ <my dir>/jdk6/x86_64/product/bin/java -XX:+DumpMiniCore -version Zing 64-Bit Tiered VM error: Unrecognized VM option '+DumpMiniCore' Could not create the Java virtual machine.
  • If the Zing version supports the -XX:+DumpMiniCore option, but the ZST version does not, a warning message is issued. For example:

     
    $ /bin/java -jar -XX:+DumpMiniCore -version Zing VM Warning: -XX:+DumpMiniCore is not supported by this ZST (found API version 0x5e, requires API version >= 0x5f) java version "1.7.0-internal-zing_99.99.99.99.dev" Zing Runtime Environment for Java Applications (build 1.7.0-internal-zing_99.99.99.99.dev-b25) Zing 64-Bit Tiered VM (build 1.7.0-zing_99.99.99.99.dev-b501-product-azlinuxM-X86_64, mixed mode)

Setting the Zing Mini-Core File Option

Include the option -XX:+DumpMiniCore with your Java launch command.

Some failures cannot be effectively diagnosed with a mini-core file. In this case, Azul support may request that you try to reproduce the failure and produce a full-sized core file, by removing -XX:+DumpMiniCore from your Java launch command.

  • When -XX:+DumpMiniCore option is not specified, a full core file, including the application objects stored in the Java heap, is created if Zing crashes.

  • When -XX:+DumpMiniCore option is specified, a core file, that does not include the application objects stored in the Java heap, is created if Zing crashes.

Speculative Locking Options

Speculative Locking in Zing leverages the Intel® Transactional Synchronization Extensions (Intel® TSX) instruction set, to take advantage of the situation where there is lock contention between threads, but no data contention inside the locked region. If a multithreaded program can concurrently modify shared data, a synchronized block or method is usually necessary to ensure correctness. This causes lock contention. The synchronization is not necessary if the concurrent accesses are to different parts of the shared data. In other words, a lock is not necessary when there is no data contention inside the locked region. For example, two different threads can modify a hash table concurrently without taking a lock, if they change values in different buckets of the hash table. Speculative Locking elides locks by speculating that there is no data contention. It does so by starting a transaction using Intel TSX instructions. If the speculation turns out to be wrong, the Intel TSX enabled CPU will detect it, abort the transaction and roll back execution to the start of lock. If a transaction gets aborted, the VM, using certain heuristics, either retries speculation or just acquires the lock as usual. The heuristic maintains aborted or attempted transactions for every speculated lock and disables speculation on that lock if it detects a high aborted or attempted value.

The following table summarizes the command-line options that control the use of speculative locking in Zing. The command lines options are case-sensitive.

Command-Line Option Description Default

-XX:[+/-]UseRTMLocking

Enables speculative locking.

false

-XX:[+/-]RTMHeuristic

Enables (Restricted Transactional Memory) RTM heuristics.

true

-XX:RTMAbortRatio=<threshold value>

Threshold value for RTM heuristics. If aborted or attempted transactions ratio goes beyond this limit for a monitor then speculation is disabled for that monitor.

50

-XX:RTMRetryCount=<attempts>

Number of times speculation is attempted on a monitor, per lock acquisition. Fewer, or no attempts will be made if internal heuristic disables speculation on the monitor.

5

Note that RTMHeuristic, RTMAbortRatio, and RTMRetryCount options are meaningful if the UseRTMLocking option is true.

Falcon Compiler Options

The Falcon compiler is an optimizing JIT (Just-In-Time) compiler that is the default Zing compiler starting from Zing release 17.03.0.0. Below are the Falcon-specific command-line options:

Option Description

-XX:[+/-]UseFalcon

Specifies which Tier 2 compiler should be used. The default Tier 2 compiler is Falcon. To use the C2 JIT instead of the Falcon JIT, run the following command:

$JAVA_HOME/bin/java -XX:-UseFalcon –cp . myprog

-Xcompilerflags:ignore|warn|error

Controls the handling of a C2 or Falcon specific flag used when the other compiler is active. The default value is "warn".

-XX:[+/-]UseFalconOSR

Controls the On Stack Replacement (OSR) functionality. OSR is enabled by default. It is not recommended to disable this option. If needed, disable it for only diagnostics purposes.

-XX:Tier2OSRThreshold=<threshold value>

Changes the threshold at which the OSR is triggered – that is loop compilation by C2 or Falcon compiler. The default value is 14000.

The value might be decreased to improve warm-up characteristics.

-XX:FalconCompileThreshold=<threshold value>

Threshold value for the Falcon JIT compiler. Replaces the identical option of the C2 compiler (-XX:C2CompileThreshold). The default value is 10000.

-XX:CompileCommand

Sets the compile threshold for a particular method, used in the following way: -XX:CompileCommand="option,<Class>::<method>,FalconCompileThreshold=<threshold value>"

-XX:+UseKestrelC2

Disables Falcon and switches to the KestrelC2 compiler.

-XX:FalconUseAVX

Specifies the highest supported AVX instructions set on x86/x64 CPUs. The default value is 2.

-XX:[+/-]FalconUseLegacyInliner

This option is deprecated with no replacement starting with the release of Zing 20.02.0.0.

Switches back to the old implementation of the LLVM inliner instead of using a highly customized integrated inliner to perform inlining optimizations in Falcon compiles.

The default value is false.

-XX:FalconOptimizationLevel=<3,2,1,0>

Controls the level of compiling optimization. The default value is 2 (full Falcon).

Suggested use: the default value is expected to fit most cases. However, if the CPU load at warmup is too high or warmup takes too long, there is a reason to try 1. The downside is that peak performance might be lower with that setting.

Accepts values from 0 to 3:

0 - minimal optimizations, lowest CPU consumption by Falcon (not recommended for production)

1 - reasonable optimizations and CPU time/warmup (good for production)

2 - aggressive optimizations, might expose high CPU utilization in some cases (default)

3 - turns on very aggressive optimizations known to cause long compilations and high CPU load at warmup. Ideally used with Cloud Native Compiler and ReadyNow to offset long compilation times.

-XX:[+/-]FalconPreserveBoxingIdentity

Disables aggressive optimization of boxing types (integer, double, etc.). Should only be used for applications which are found to rely on implementation defined behavior as opposed to the specified behavior of boxing routines.

The default value is false.

-XX:FalconGenerateProfilerInfo=<value>

Specifies the method inlining detail level for performance profiling output of compiled code. Setting a lower level may help to reduce compiled code size by a few percent.

Accepts values from 0 to 2:

0 - no method inlining information is generated

1 - stack of inlined methods is generated only (default)

2 - stack of inlined methods with bytecode indices (bci) is generated

-XX:[+/-]FalconCompensateForIntelMCUForErratumSKX102

Introduces a nop padding based mitigation for performance regressions seen on some systems following Intel’s micro code updates in response to errata SKX102.

This option is expected to become the default in a future Zing release.

If enabled, nop padding is used to align affected branches on systems with the micro code update applied.

The default value is false.

-XX:[+/-]ForceFalconCompensateForIntelMCUForErratumSKX102

Forces generation of nop padded code on unaffected systems for performance validation.

The default value is false.

-XX:[+/-]FalconOptBoxing

Enables the optimization to eliminate redundant boxing conversions.

The default value is true.

-XX:[+/-]FalconLockCoarsenOverLoop

Enables a lock coarsening optimization for loops where the lock over a loop is coarsened. This is done by chunking the loop and coarsening the lock over the chunked loop. The default value is true.

-XX:[+/-]FalconEnableAggressiveLockOpt

Enables loop chunking by chunk size of 32 and performs lock coarsening over the loop. Additionally, enables lock coarsening over memory operations with monitor exit when valid to do so. The default value is true.

-XX:[+/-]UseMultiTiering

Enables Multi-Tiering, allowing Falcon to assign methods to more than just one Falcon optimization level, assigning methods for either mid-tier or final-tier compilation. Final-tier compilation uses the default Zing optimizations (usually Falcon optimization level 2) and mid-tier compilation uses Falcon optimization level 0. Multi-Tiering is disabled by default.

NOTE: The Falcon compiler is available for Java 7, Java 8, Java 11, Java 13, and Java 15. An attempt to use the -XX:+UseFalcon option for Java 6 will cause a failure.

Optimizer Hub Options

Below are the command-line options for Optimizer Hub to interact with Cloud Native Compiler and ReadyNow Orchestrator.

Cloud Native Compiler JVM Options

Note
The minimum JVM options to request compilations from Cloud Native Compiler are -XX:OptHubHost=<host:port> and -XX:+CNCEnableRemoteCompiler.
Command Line Option Description Default

-XX:OptHubHost=<dns>

DNS where Optimizer Hub is listening. See Configuring Optimizer Hub Host.

-XX:[+/-]CNCEnableRemoteCompiler

Allows usage of the remote compiler when Cloud Native Compiler has established a connection.

false

-XX:CNCEngineUploadAddress=<dns>

DNS where Optimizer Hub is listening. Configuring Optimizer Hub Host.

-XX:[+/-]CNCAbortOnBadChannel

With this flag, the JVM crashes if it loses connection with a Cloud Native Compiler.

false

-XX:[+/-]OptHubUseSSL

Instructs Zing to communicate directly with Optimizer Hub without using SSL. Use this option if you installed Optimizer Hub without SSL.

true

-XX:OptHubSSLRootsPath=<path to cert.pem>

Instructs Zing to use and trust a specified SSL certificate on the filesystem.

-Xlog:[+/-]concomp

Display messages describing communication with Optimizer Hub.

false

ReadyNow Orchestrator JVM Options

The following options are available in Azul Prime when using the ReadyNow Orchestrator with Optimizer Hub:

Command Line Option Description Default

-XX:OptHubHost=<dns>

Address where Optimizer Hub is listening. See Configuring Optimizer Hub Host.

-XX:ProfileName=<name>

Name of the profile that the JVM both reads from and writes to. Use of this flag is equivalent to using -XX:ProfileLogIn=<name> -XX:ProfileLogOut=<name>, and is the preferred way to specify profile names when different input and output names are not needed. If prefixed with opthub://, <name> is used as the profile name in ReadyNow Orchestrator. If not prefixed with opthub://, <name> is interpreted as a file path on the JVM.

null

-XX:[+/-]EnableRNO

Enables ReadyNow read and write to ReadyNow Orchestrator. Requires OptHubHost and uses ProfileName as the name for the profile log.

false

-XX:ProfileLogOut=<name>

The ProfileLogOut enables Zing to record compilations from the current run. <name> is the name of the profile that the JVM reads as input to ReadyNow. If prefixed with opthub://, <name> is used as the profile name in ReadyNow Orchestrator. If not prefixed with opthub://, <name> is interpreted as a file path on the JVM.

Note
For local ReadyNow you often have to specify different names for ProfileLogIn and ProfileLogOut. But for ReadyNow Orchestrator you must only use ProfileName.

null

-XX:ProfileLogIn=<name>

The ProfileLogIn allows Zing to base its decisions on the information from a previous run. The current ProfileLogIn file information is read in its entirety - before Zing starts to create a new ProfileLogOut log. <name> is the name of the profile that the JVM reads as input to ReadyNow. If prefixed with opthub://, <name> is used as the profile name in ReadyNow Orchestrator. If not prefixed with opthub://, <name> is interpreted as a file path on the JVM.

Note
For local ReadyNow you often have to specify different names for ProfileLogIn and ProfileLogOut. But for ReadyNow Orchestrator you must only use ProfileName.

null

-XX:ProfileLogOutNominationMinSize

Indicate to server that the produced profile is eligible for promotion after specified amount of bytes recorded.

0 = any size eligible

-1 = will never be promoted

1M

-XX:ProfileLogOutNominationMinSizePerGeneration

Define minimum acceptable amount of bytes per generation which the profile size should reach to become eligible for promotion. In case a generation is missing in the list specified in the -XX:*PerGeneration option, it inherits a value from the previously specified generation or the corresponding default (either -XX:*MinSize or -XX:*MinTimeSec), if there is no previous generation specified.

Comma seperated list of pair <generation>:<size>.

null

-XX:ProfileLogOutNominationMinTimeSec

Define the minimum time, in seconds, a profile must record before ReadyNow Orchestrator will nominate it as a candidate.

0 = any duration eligible

-1 = will never be promoted

120

-XX:ProfileLogOutNominationMinTimeSecPerGeneration

Define the minimum time, in seconds, per generation during which the profile should be recorded in order to become eligible for promotion. In case a generation is missing in the list specified in the -XX:*PerGeneration option, it inherits a value from the previously specified generation or the corresponding default (either -XX:*MinSize or -XX:*MinTimeSec), if there is no previous generation specified.

Comma seperated list of pair <generation>:<size>.

null

-XX:ProfileLogOutMaxNominatedGenerationCount

When used with ReadyNow Orchestrator, specifies the maximum generation of a profile that a VM will nominate. This JVM command line parameter overrides the serverside default to configure ReadyNow Orchestrator.

0 = unlimited

0

-XX:ProfileLogMaxSize=<value in bytes>

Specifies the maximum size that a ReadyNow profile log is allowed to reach. Profiles will be truncated at this size, regardless of whether the application has actually been completely warmed up.

This JVM command line parameter overrides the serverside default to configure ReadyNow Orchestrator.

It is recommended to either not set this size explicitly, or set it generously if required, for example:

-XX:ProfileLogMaxSize=1G

0 = unlimited

0

-XX:ProfileLogTimeLimitSeconds=<value in seconds>

Instructs ReadyNow to stop adding to the profile log after a period of N seconds regardless of where the application has been completely warmed up. It is recommended to either not set this size explicitly, or set it generously if required.

0 = unlimited

0

-XX:ProfileLogDumpInputToFile=<name>

Dumps input profile to the specified path. For debugging purposes only.

null

-XX:ProfileLogDumpOutputToFile=<name>

Dumps output profile to the specified path. For debugging purposes only.

null

-XX:RNOConnectionTimeoutMillis

Timeout on establishing remote connection and timeout on interval between downloading two chunks. Specified in milliseconds.

5000

-XX:RNOProfileFallbackInput

Experimental feature. Local filesystem path which gets used in case no profile data is downloaded. E.g., in case of a missing connection or the requested profile name doesn’t exist on the server.

null

-XX:ProfileLogOutVerbose

Enables logging of verbose, optional tracing information in -XX:ProfileLogOut

true

-XX:ApplyReadyNowTransformations

Enables ReadyNow transformations at runtime.

You can apply your transformation options directly in the parameters on the command line, e.g. -XX:ApplyReadyNowTransformations="\{transformations\:\[\{data: 0\}\]\}"

Alternatively, a transformation profile can be stored on your machine in yaml format and called using, e.g. -XX:ApplyReadyNowTransformationsFile=//path/to/file.yaml.

null

CPU Budgeting Options

These CPU Budgeting options are applicable to the Falcon Tier 2 Compiler.

Flag Description Default

-XX:[+/-]EnableTier2CompilerBudgeting

Enables CPU budgeting options for the C2 compiler.

false

-XX:CIMaxCompilerThreads=<number of threads>

Defines the maximum number of threads which can be dedicated to the compiler.

Dependent on the CPU count

-XX:CIMaxCompilerThreadsPercent=<percent of threads>

Defines the maximum number of threads, as a percent, which can be dedicated to the compiler. The number of threads is rounded up to the nearest whole number. Use the option CompilerTier2BudgetingCPUPercent instead to use a fractional value.

Dependent on the CPU count

-XX:CompilerWarmupExtraThreads=<number of threads>

Defines how many extra threads over CIMaxCompilerThreads the C2 compiler can use during warmup, before the Main class in compiled. After warmup, the value of CIMaxCompilerThreads shall be respected.

0

-XX:ProfilePreMainTier2ExtraCompilerThreads=<number of threads>

Defines how many extra threads over CIMaxCompilerThreads the C2 compiler can use during warmup, before Main class is compiled.

0

-XX:CompilerWarmupPeriodSeconds=<value in seconds>

Defines how long the C2 compiler warmup period shall be, in seconds.

0

-XX:CompilerTier2BudgetingWarmupCPUPercent=<value>

Specifies the number of threads, as a percent, which can be used for C2 compilation during warmup. The resulting value can be less than 1 thread or any other non-whole number of threads. The C2 compiler waits for this percent of threads to be available before continuing.

0

-XX:CompilerTier2BudgetingCPUPercent=<value>

Specifies the number of threads, as a percent, which can be used for C2 compilation post warmup.

67

-XX:CompilerTier2BudgetWindowDurationMs=<value in ms>

Specifies a window of time, in ms, in which the average CPU consumption of the compiler shall not exceed CompilerTier2BudgetingCPUPercent.

1000

Compilation Ranks by Priority

These options allow the Falcon Tier 2 Compiler to assign compilation ranks to methods based on min-time-between-promotions. Each method, based on its min-time-between-promotions value, is assigned a rank: hot, warm, or cold. For more information on compilation ranks, see Analyzing and Tuning Warmup.

Flag Description Default

-XX:TopTierCompileThresholdTriggerMillis=<value in ms>

Previously TopTierCompileThresholdMs - Controls the triggering time limit (in ms) in which the method needs to reach the compile threshold in order to be queued for compilation. If the threshold is reached, but not within this time limit, the method is ignored and the timer starts over again.

This option assigns the same value to TopTierHotCompileThresholdTriggerMillis and TopTierWarmCompileThresholdTriggerMillis, creating a boundary between hot and cold ranks while eliminating the warm rank.

This option must not be set if you are using TopTierHotCompileThresholdTriggerMillis and TopTierWarmCompileThresholdTriggerMillis to specify hot, warm, and cold ranks.

60000

-XX:TopTierHotCompileThresholdTriggerMillis=<value in ms>

Sets an upper bound for min-time-between-promotions for the hot rank and a lower bound for the warm rank. The upper bound for the hot rank is 1ms less than the value set.

60000

-XX:TopTierWarmCompileThresholdTriggerMillis=<value in ms>

Sets the upper bound for min-time-between-promotions for the warm rank and lower bound for the cold rank. The upper bound for the warm rank is 1ms less than the value set.

600000

-XX:TopTierWarmCompileCpuPercent

Specifies the percentage of CPU time from the total budget available to compiler threads that can be spent on warm rank compilation. hot ranks are given 100% and cold ranks are given 0%.

25

The default settings for compilation ranking by priority sets the following ranks:

  • hot: 0-59999ms min-time-between-promotions, budget 100%

  • cold: 60000-599999ms min-time-between-promotions, budget 25%

  • skip: 600000ms-inf min-time-between-promotions, budget 0%

ReadyNow Options

Below are the ReadyNow-specific command-line options:

Option Description Default

-XX:ProfileLogOut=<filename>

ProfileLogOut enables Zing to record compilations from the current run. <filename> is the name of the profile that the JVM reads as input to ReadyNow. If prefixed with cnc://, it will attempt to pull the profile from Cloud Native Compiler.

If ReadyNow is configured as a rolling profile (with ProfileLogIn equal to ProfileLogOut), The JVM creates a backup of the input profile at startup before the profile is being read into memory. Otherwise, the file will be overwritten.

null

-XX:ProfileLogIn=<filename>

ProfileLogIn allows Zing to base its decisions on the information from a previous run. The current ProfileLogIn file information will be read in its entirety - before Zing starts to create a new ProfileLogOut log. <filename> is the name of the profile that the JVM reads as input to ReadyNow. If prefixed with cnc://, it will attempt to pull the profile from Cloud Native Compiler.

null

-XX:ProfileLogName=<name>

Name of the profile that the JVM both reads from and writes to. If prefixed with cnc://, it will attempt to write from Cloud Native Compiler.

Replaces ProfileLogIn and ProfileLogOut. Can be used in place of -XX:ProfileLogIn=<profile1> -XX:ProfileLogOut=<profile1>

null

-XX:ProfileLogDumpInputToFile=<name>

Dump input profile to the specified path. For debugging purposes only.

null

-XX:ProfileLogDumpOutputToFile=<name>

Dump output profile to the specified path. For debugging purposes only.

null

-XX:ProfileLogMaxSize=<value>[K|M|G]

Specifies the maximum size that a ReadyNow profile log is allowed to reach. Units can be specified in kilobytes (K or k), megabytes (M or m), or gigabytes (G or g). Profiles will be truncated at this size, regardless of whether the application has actually been completely warmed up. It is recommended to either not set this size explicitly, or set it generously if required, for example:

-XX:ProfileLogMaxSize=1G

0 = unlimited

0

-XX:ProfileLogOutMaxNominatedGenerationCount=<value>

When used with Cloud Native Compiler, specifies the maximum generation of a profile that a VM will nominate. If ContinueRecordingAfterPromotion (CNC server-side parameter) is set to false (default), then the JVM will not output another generation after this limit has been reached. If ContinueRecordingAfterPromotion is true, the JVM will output another generation to Cloud Native Compiler but will never nominate it. These additional generations are for debugging and analysis only.

0 = unlimited

0

-XX:ProfileLogOutNominationMinTimeSec=<value in seconds>

When used with Cloud Native Compiler, the minimum time, in seconds, a profile must record before CNC will nominate it as a candidate. If no -XX:ProfileLogOutNominationMinTimeSec is set, then the candidate is nominated by CNC when -XX:ProfileLogTimeLimitSeconds is reached.

0 = any duration eligible, -1 means it will never be promoted

120

-XX:ProfileLogTimeLimitSeconds=<value in seconds>

Instructs ReadyNow to stop adding to the profile log after a period of N seconds regardless of where the application has been completely warmed up. It is recommended to either not set this size explicitly, or set it generously if required.

0 = unlimited

0

-XX:ProfileLogServiceConnectionTimeoutMillis=<value in ms>

Timeout on establishing remote connection and timeout on interval between downloading two chunks. Specified in milliseconds.

5000

-XX:ProfileLogOutNominationMinSize=<value in bytes>

Indicate to server that the produced profile is eligible for promotion after specified amount of bytes recorded.

0 = any size eligible, -1 means it will never be promoted

1m

-XX:[+/-]ProfileLogOutVerbose

Enables logging of verbose, optional tracing information in -XX:ProfileLogOut

true

Compile Stashing Options

Compile Stashing is a Zing feature that caches compiles performed in one run and reuses them in subsequent runs.

For more information on Compile Stashing, see Using Compile Stashing

Use the following command-line options to control caching and enable reporting:

Option Description Default

-XX:[+/-]FalconUseCompileStashing

Enables/disables Compile Stashing, populates the cache.

false. Before 19.12.0.0, true if -XX:ProfileLogOut is set.

-XX:FalconObjectCacheRoot=<path>

Sets the cache location. By default, different instances of Zing running on the same host share the same stash location. However, different instances can be configured to use different locations via the FalconObjectCacheRoot option.

$HOME/.zing/falcon-cache/<zvm_version>/

-XX:[+/-]FalconLoadObjectCache

Enables loading from compile cache.

false

-XX:[+/-]FalconSaveObjectCache

Enables saving to compile cache.

false

-XX:FalconMaxStashedCompileSize=<max_size in bytes>

Specifies the maximum size of a stashed compile entry. When running multiple virtual machines concurrently, different cache sizes for different virtual machines are not recommended. Similar cache sizes are advised.

0

-XX:FalconMaxCacheSize=<max_size in bytes>

Specifies the maximum size of the compile cache.

10 GB

1-XX:[+/-]FalconObjectCachePrintReport

Prints stashing statistics.

false

-XX:[+/-]FalconObjectCachePrintPrecompilationReport

Prints stashing report at the end of ReadyNow precompilation.

false

Tick Profiler Options

The Tick Profiler provides information to allow calculation of how processor resources are used for an interval of recorded time. Below is the Tick Profiler-specifc command-line option:

Option Description Default

-XX:[+/-]UseTickProfiler

Enables and disables profiling of processor core time spent between various software execution units (for example, threads, methods, and run-time tasks).

Due to known issues with version 3.10 and earlier Linux kernels, including those used in RHEL 7.x and CentOS 7.x, using +UseTickProfiler in production should be done with caution, as potential hangs may result under heavy loads.

false

Out-of-Memory Options

Out-of-Memory command-line options let the JVM handle out-of-memory occurrences:

Option Description Default

-XX:[+/-]ExitOnOutOfMemoryError

Enables the JVM exit on the first occurrence of an out-of-memory error. Useful if you prefer restarting an instance of the JVM to handling out of memory errors.

false

-XX:[+/-]CrashOnOutOfMemoryError

Enables the JVM crash and produce text and binary crash files when an out-of-memory error occurs.

false

Flight Recorder Options

Flight Recorder command-line options gather and register events that help to understand the behavior of a Java Application and Zing:

Option Description Default

-XX:[+/-]FlightRecorder

The Java Flight Recorder (JFR) is always available in Zing, this flag is not needed to use JFR.

This flag is useful only to prevent JFR from being activated by users or from within an application. That can be achieved by adding -XX:-FlightRecorder to the command line. It gives no performance benefit.

See Using Java Flight Recorder for details.

false

JFR remains available until -XX:-FlightRecorder is set

-XX:StartFlightRecording

Starts a flight recording from the command line with recording parameters provided as a value for this option.

For example, -XX:StartFlightRecording=filename=myrecording.jfr starts a recording in the file system while -XX:StartFlightRecording=disk=false,filename=myrecording.jfr starts an in-memory recording. In both cases the result is written to the myrecording.jfr file at the end of the JVM session. For the description of additional Java Flight Recording (JFR) parameters refer to JFR resources available in the Internet.

null

-XX:FlightRecorderOptions

Specifies additional parameters to configure Java Flight Recorder (JFR). For the description of additional JFR parameters refer to JFR resources available in the Internet.

null

-XX:JFRDescribeLiveSetPercentage=<value>

Specifies the percentage amount of a live set to be described by recorded JFR events. To omit some minor events from the recording, change the value of this option to a smaller number, e.g., 90.

99

-XX:[+/-]UseTickProfilerAsJFRThreadSampler

Enables Zing to use the Tick Profiler instead of the JFR Thread Sampler. When set to true, EventExecutionSample JFR events are generated from data provided by the Tick Profiler.

true

-XX:TickProfilerNotifierIntervalMillis=<value in ms>

Controls the interval between consecutive polls for the new Tick Profiler samples to pass them to the JFR in-memory buffer. This option has an effect only when -XX:+UseTickProfilerAsJFRThreadSampler is specified.

200

Zing MXBean Options

Zing MXBean command-line options help monitor the Zing heap utilization:

Option Description Default

-XX:[+/-]ReportUsedAsCommitted

The MemoryMXBean.getHeapMemoryUsage() method of MXBeans API returns the value of the Committed memory equal to the amount of JVM heap memory guaranteed as available for running an application (see Understanding Heap Memory Management for details). To switch to the old behavior of the MXBeans interface that returned the value of the Committed memory equal to Used memory, change the value of this option to true.

false

-XX:[+/-]MimicG1GCMemoryManagerNames

Changes garbage collector names returned by GarbageCollectorMXBean from GPGC to G1. To define exact New and Old GC names use -XX:GPGCNewGCMemoryManagerName="GPGC New" and -XX:GPGCOldGCMemoryManagerName="GPGC Old" respectively. This option provides a workaround for applications that do not recognize GPGC names such as Logstash.

false

-XX:GPGCNewGCMemoryManagerName=<New collector name>

Sets the name returned by GarbageCollectorMXBean for the New generation collector.

GPGC New

-XX:GPGCOldGCMemoryManagerName=<Old collector name>

Sets the name returned by GarbageCollectorMXBean for the Old generation collector.

GPGC Old

-XX:[+/-]IncludeNonObjectHeapInReportedJavaHeap

Makes Java heap reporting APIs and Tools include "non-object" use.

false

-XX:[+/-]ReportConstantMaxPossibleHeapAsMaxJavaHeap

Lets APIs which report max heap capacity be aware of elasticity.

false