Azul FAQs

First, let's differentiate between Zing ZVM versions and Java SE level. The Java SE level is for exampleJava 8, or also written as 1.8.0. The ZVM version providing the actual implementation is for example16.12.0.0.

Both version numbers are part of the ZVM installation path. Here an example:/opt/zing/zing-jdk1.8.0-16.12.0.0-12-x86_64

You can always install and use multiple Java SE Levels each using a different ZVM version.

But if you want to install and use different ZVM versions providing the same Java SE level, you need to use the ZVM tar.gz or .sh installation packages available on https://www.azul.com/software-downloads-and-documents/.

The ZVM RPM and DEB packages always replace the previously installed ZVM version. The tar.gz and .sh packages do not modify any previous installation.

Documentation reference:

Zing Software Downloads

Zing User Guide - Installation and Configuration

Zulu 8 versions 8.25 through 8.41 and Zulu 11 versions of 11.34 and before use a slightly different default setting for the text rendering of the font library libfreetype. The rendering setting v40 is enabled on those versions. Since Zulu versions 8.42 and 11.35 the original setting v35 is used again by default.

If you see unexpected differences in the font rendering appearance on those Zulu versions listed above, use the following commands in your system environment or application start script to switch to the v35 setting:

Linux and macOS:

export FREETYPE_PROPERTIES=truetype:interpreter-version=35

Windows:

set FREETYPE_PROPERTIES=truetype:interpreter-version=35

Depending on the fonts used by the application the hinting details are interpreted differently on v40 which can lead to changes in the stroke width and pixel alignment of vertical glyph lines.

See also

Using Fonts with OpenJDK / Zulu

Font rendering and glyph spacing changed from jdk-8 to jdk-11

Setting global environment variables on Windows

Both are JVMs and are available not only for the latest stable JDK major version but also for earlier major versions like JDK 8 and others as supported products.

Zing's typical use cases are applications with requirements regarding low latency response time or huge heap sizes in the range of hundreds of GBytes or both combined. Zing is limited to Linux x86 64 bit. Zing includes its own Garbage Collection implementation (C4) and its own JIT compiler implementation (Falcon).

Zulu covers more general use cases as it is mainly OpenJDK with its Garbage Collectors like CMS GC, G1 GC, Parallel GC and the Hotspot JIT. It is available for a large variety of CPU architectures and Operating Systems from servers over desktops to embedded systems.

Further details:

Zing

Zulu Enterprise

Zulu Embedded

Azul Product Support Lifecycle

The Zing product is built for Linux. It cannot natively run on Mac OS X or on Windows.

For more on supported Linux distros, please review the Zing Technical Specifications.

The definitive list of Linux distros, kernel versions, processors, and memory limits is covered fully in the Zing Systems Requirements document, updated for each Zing release.

This article refers to using Zing with the ZST component. Since ZVM 19.07 the ZST component is optional and depending on your use case Zing without ZST might be the preferred choice now as by its different memory management it is not affected by the problem described here. For large heapsizes (-Xmx setting) of hundreds of GBytes the ZST component adds performance advantages for most applications.

If you get this error when trying to launch an application it means that Zing was unable to reserve enough memory to launch the application.

When you launch an application on Zing it reserves some of your system's RAM for its own use. At a minimum Zing will reserve a chunk of memory equal to your heap size (Xmx). If no other Zing apps are already running it will reserve an additional chunk of memory, usually about 7% of system RAM, for the Zing Contingency Memory and Pause Prevention pools.

If Zing can't reserve all of the memory that it needs it will throw this error: Memory management: unable to fund java heap account and your application won't start.

You can check system memory usage with the 'free' and 'zing-ps -s' command. The zing-ps command also shows the absolute maximum upper limit available for -Xmx values. Those are usually defined as 75% or 85% of the system RAM in /etc/zing/pmem.conf depending on the Zing version.

This failure to start can also happen if there are not enough free 2MB pages and 4MB pages for Zing available due to memory fragmentation. To check that, please run "grep Normal /proc/buddyinfo" and look at the last two columns to see if there are sufficient 2 and 4 MBytes pages.

Example of one machine with zero 2M and 4M pages available:

$ grep Normal /proc/buddyinfoNode 0, zone Normal 168 69 184 186 182 109 71 386 492 0 0

If no large other processes are occupying memory, then the cause of memory fragmentation might be a high usage activity of the Linux page cache (file system cache). In that situation you can tell the operating systemto write back the cache to disk to free memory. Please take care when using the following on a production system if an application is already running in parallel on it as writing all file system cache content back to disk can take seconds to a few minutes on machines with hundreds of GBytes of RAM and temporarily increases I/O load significantly!

To flush the page cache (file system cache):

syncecho 1 | sudo tee /proc/sys/vm/drop_caches

Since Zing ZST 5.21.7 this situation is resolved much better with Zing automatically. Please consider upgrading the Zing ZST component if you experience this problem often. Zing ZST is available for download on https://www.azul.com/software-downloads-and-documents/. In addition since ZST 5.21.7, an enhanced memory defragmentation can be enabled in Zing: https://docs.azul.com/zing/index.htm#ZingAppA_EnhancedLinuxMemoryDefragmentation.htm

If the recommendations above don't work for you, reboot the system or contact our support: https://www.azul.com/support/

This article refers to Zing when using it with the now optional component ZST. Since ZVM 19.07 the ZST component is not required any more and depending on your use case Zing without ZST might be the preferred choice now as by its different memory management it is not affected by the problem described here. Though for large heapsizes (-Xmx settings) of hundreds of GBytes, the ZST component adds performance advantages for most applications.

Zing when used with the ZST component preallocates a chunk of memory to hold the entire Xmx value setting to house regular Java objects that get allocated on the heap, plus additional spaces for other data types.

The first choices you make in reserving memory in Zing are how much memory to reserve and when in the JVM process life cycle you want it allocated. Use theutilitysystem-config-zing-memory in the Zing Systems Tools set to make your choices.

For Zing with ZST the two available policies for determining when to preallocate Zing memory are:

reserve-at-config

reserve-at-launch

Selecting reserve-at-config will preallocate all the Zing memory at once. Memory stays allocated, no matter how many times the ZVM starts or stops. This is the mode you might prefer if you know that on this host only Zing java processes are used and their -Xmx settings are not changed often. It is also the preferred mode on large machines in the range of hundreds of GBytes for the -Xmx setting.

Selectingreserve-at-launch will preallocate all the Zing memory when the Zing java process starts, and releases it when the process ends. This is the mode you might prefer if Zing java is not always used on this host, like on developer machines, or if you have a mixed environment with other processes running.

When doing new installation of Zing, the memory allocation policy is set to reserve-at-launch by default to simplify the installation and to avoid to preallocate too much memory for Zing.

For further details about the Zing memory configuration using sudo system-config-zing-memory, please go to the following documentation page: http://docs.azul.com/zing/index.htm#ModZingMemConfig.htm

Zing runs on most Virtual Machines. For details see Does Zing run on a Virtual Machine? Only the followingdetail needs to be taken care of for production systems if you use Zing with the ZST component. Since ZVM 19.07 the ZST component is not required any more and only an optional tuning and depending on your use case Zing without ZST might be the preferred choice now as by its different memory management it is not affected by the problem described here.

VMware, VirtualBox, Xen and other hypervisor systems try to utilize the hardware resources as efficient as possible. Sometimes, overcommitting CPU and memory resources is activated, which is obviously dangerous for productions systems and usually limited to test and developer systems. But even without overcommitting activated, the VM Balloon Driver is running on most standard Linux systems by default. This driver tries to mark rarely used VM memory for reassigningit either for overcommitting or also for other actions like creating snapshots or relocation of VMs to other hosts or offering more memory to the host system if the host is used for other tasks in parallel, like using a VM on a small system like a notebook.

Unfortunately, the Balloon Driver is unaware of memory pages locked by other processes. This is a known bug in VMware tools and also Open-VM-Tools: VMware KB 1003586

As the Zing Java Virtual Machine (ZVM) is using locked memory pages provided by the Zing System Tools (ZST) and the Balloon Driver is ignoring them, wrong assumptions are made over the actual used memory. If the hypervisor now needs more memory, for example whenother applications are used on a laptop in parallel to VMware, the result will be most likely a killed JVM process inside the VM.

The reason for the killed process is the memory pressure the balloon driver creates by over-expanding its virtual balloon as it considers the memory used by Zing as free to be reclaimable by itself. The virtual balloon won't overwrite the amount of Zing memory defined by the -Xmx parameter, but it would fill the remaining free Linux system memory completely. So other than in normal use cases of the balloon driver where it leaves some Linux memory remaining as buffer, none is left here. As a consequence of no free memory available any more, the Linux Out Of Memory Process Killer activates itself, selecting the largest process, which is most likely the Zing process and thereby terminating the java process.

This is visible by the following messages listed by "dmesg" or logged in related files like /var/log/syslog:

java invoked oom-killerOut of memory: Kill process 6465 (java) score 38 or sacrifice childKilled process 6465 (java) total-vm: ...

Solution

Disable the Balloon Driver,either by changes in the hypervisor or by changing the VM configuration file.

For VMware add the following line to the VMX file and restart the VM:sched.mem.maxmemctl = "0"

Alternatively, you can disable the balloon driver within the VM:

Find the module name: /sbin/lsmod | grep balloonRemove the module: sudomodprobe-rvmw_balloon

Balloon Driver onVirtualBox: https://www.virtualbox.org/manual/ch04.html#guestadd-balloon

Balloon Driver on Xen: https://lists.gt.net/xen/users/314755

ThreadLocal variables are useful when we want to have a thread safe instance and wedon'twant to use synchronization as the performance cost with synchronization is more. One such case is when SimpleDateFormat is used OR when we have a requirement to associate state with a thread, then also ThreadLocal can be used.

But when running it with Zing before version ZVM 18.12, you may observe some performance issues due to the concurrent nature of the collector. If you face any performance issues, you can add the following parameter -XX:+UseModifiedThreadLocal to the JVM options and rerun the application. Make sure to test the application properly. Since ZVM 18.12 this setting is the default.

Since Zing ZVM 19.07 no sudo or root privileges are needed any more for Zing on the current versions of the supported operating systems.

The Zing System Tools (ZST), a Linux system service, is since then only required on older operating systems, for example on RHEL 7.2 and previous versions.

The Documentation on the following pages uses the installation without ZST as default:

https://docs.azul.com/zing/start.htm https://www.azul.com/zing-trial-download/

To be more precise: To install RPM or DEB packages of Zing ZVM you still need, due to the nature of these packaging system, system administrator permissions, but now you can also install and run Zing ZVM just from the tar.gz package.

Please note: Since Zing ZVM 19.07 you don't need the Zing ZST component any more on current operating system versions. See also: Do I need root or sudo rights to install Zing?

This page describes the installation using DKMS when Zing was installed from the Azul software repository as described in http://docs.azul.com/zing/index.htm#InstallZing.htm or during the Zing 30 day free trial from http://docs.azul.com/zing/zing-quick-start.htm.

If you are using the manually downloaded version of Zing, please visit the following page instead: Instructions for DKMS with Zing manually downloaded

On Amazon Linux or Debian the method utilizingDKMS as described in this article is already the default, so the instructions described on this page won't add anything and should not be used.

DKMS in general solves the situation when the Zing System Tools (ZST) are not yet available for the Linux Kernel Version of your system. In those situations, DKMS (Dynamic Kernel Module Support) then builds ZST for thisspecific system. DKMS is usually only required if you see the following error message when starting the Zing Memory Service:

# sudo service zing-memory restartinsmod: ERROR: could not insert module /lib/modules/zing-driver/extra/zing_mm.ko: Invalid parameterszing-memory: ERROR: insmod /lib/modules/zing-driver/extra/zing_mm.ko failed (error 1)zing-memory: INFO: Zing ZST support for kernel 3.8.13-118.14.2.el7.x86_64 is unavailable. Please upgrade ZST.

For most installations utilizing DKMS is not necessary as the ZST packages in the Azul software repository are updated every 24 hours in case a Linux vendor releases a new kernel update. If you can delay the upgrade of your system for this period of time until the software repository provides the updated ZST, you don't need the DKMS approach. Though for custom kernels the DKMS approach is still the preferred one.

The dkms tool is already included in Ubuntu, SLES, Debian and Amazon Linux but not directly provided by CentOS, RHEL and Oracle Linux. For those systems it should be installed from the EPEL (Extra Packages for Enterprise Linux) repository as described below. The first line uninstalls the non-DKMS Zing ZST package in case it was already installed before. If you are wondering about the path name "amazonlinux": We are using this Zing repository as it contains the DKMS version of ZST. It is compatible to other RPM based systems like RHEL or CentOS.

The following steps are intended for RHEL / CentOS / Oracle Linux 7.x. For version 6.x replaceepel-release-latest-7.noarch.rpm byepel-release-latest-6.noarch.rpm.

If ZST was already installed in its non-DKMS version make a backup of its configuration and then remove the installed ZST:

# mkdir zst-config# cp -v /etc/zing/pmem.conf.* zst-config# sudo yum remove zing-zst

Now ZST for DKMS will be installed:

# sudo yum install yum-utils "kernel-devel-uname-r == $(uname -r)"# sudo curl -O https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm# sudo curl -o /etc/yum.repos.d/zing.repo http://repos.azul.com/zing/amazonlinux/zing.repo# sudo yum cleanmetadatadbcache#sudo yum install epel-release-latest-7.noarch.rpm#sudo yum-config-manager --disable epel#sudo yum --enablerepo=epel install dkms#sudo yum install zing-zst zing-jdk1.8.0

If you are using the Zing 30 day free trial you might still need to acquire the license. For that continue in step 2 (License Zing) as documented in Zing Quick Start Guide.

Afterwards, run the following commands to verify that ZST is completely installed and Zing is working:

# sudo service zing-memory status# /opt/zing/zing-jdk8/bin/java -version

On later kernel updates triggered by rpm or yum, the dkms-based ZST will the be rebuild automatically and no user interaction is necessary.

If for some reason, the dkms-based ZST has to be rebuild and reinstalled manually, please use the following commands, but replace the version numbers according to your system:

# sudo dkms statuszing_mm, 5.16.0.0-3, 4.4.0-53-generic, x86_64: installedzing_mm, 5.16.0.0-3, 4.4.0-59-generic, x86_64: installed#sudo dkms build zing_mm/5.16.0.0-3#sudo dkms install zing_mm/5.16.0.0-3

In case the EPEL mirrors cannot be reached on later upgrades, please reinstall the EPEL.rpm to receive the updated mirrors list:

# sudo curl -O https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm# sudo yum reinstall epel-release-latest-7.noarch.rpm

This page describes the installation using DKMS when Zing was installed from the Azul software repository as described in http://docs.azul.com/zing/index.htm#InstallZing.htm or during the Zing 30 day free trial from http://docs.azul.com/zing/zing-quick-start.htm.

For the installation of the licensed version of Zing on those systems, please visit instead Instructions for DKMS with Zing manually downloaded.

Please note: Since Zing ZVM 19.07 you don't need the Zing ZST component any more on current operating system versions. See also: Do I need root or sudo rights to install Zing?

This page describes the installation using DKMS when Zing was manually downloaded from http://www.azul.com/downloads/software-downloads-and-documents.

If you are using the Zing Trial or install Zing from the repository, please visit the following page instead: Instructions for DKMS with Zing installed from the repository

DKMS in general solves the situation when the Zing System Tools (ZST) are not yet available for the Linux Kernel Version of your system. In those situations, DKMS (Dynamic Kernel Module Support) then builds ZST for thisspecific system. DKMS is usually only required if you see the following error message when starting the Zing Memory Service:

# sudo service zing-memory restartinsmod: ERROR: could not insert module /lib/modules/zing-driver/extra/zing_mm.ko: Invalid parameterszing-memory: ERROR: insmod /lib/modules/zing-driver/extra/zing_mm.ko failed (error 1)zing-memory: INFO: Zing ZST support for kernel 3.8.13-118.14.2.el7.x86_64 is unavailable. Please upgrade ZST.

For most installations utilizing DKMS is not necessary and our non-DKMS packages available on http://www.azul.com/downloads/software-downloads-and-documents with the standard documentation at http://docs.azul.com/zing should be used.

An alternative to DKMS for those use cases where the Linux kernel is always upgraded to the most recent release of the OS vendor, is to attach the Zing software repository as described in http://docs.azul.com/zing/index.htm#InstallZing.htm and thereby upgrading ZST automatically when the Linux kernel is upgraded on the system. The ZST software packages in the repository are currently updated every 24 hours in case a kernel update is released. Though for custom kernels, this approach won't work and DKMS is still the preferred solution then.

The dkms tool is already included inUbuntu, SLES, Debian and Amazon Linux. On those systems it is sufficient to just install the ZST DKMS-based package from the download page listed above and you don't need to read further. For other systems, like CentOS, RHEL and Oracle Linux the dkms tool is not part of the operating system, but it can be installed from the EPEL (Extra Packages for Enterprise Linux) repository as described in the following steps.

Before starting with DKMS, make sure you can revert your system state by using a VM snapshot or system backup in case the installation fails.

The version numbers like3.10.0-514, 5.16.0.0 and package names with version numbers on this page are just examples, you need to replace them with the actual versions of the current Linux and ZST version.

To add the dkms tool, these steps are necessary:

If you are using Oracle Linux, check if the Oracle Unbreakable Enterprise Kernel (UEK) is used or not:

The following output is an example for an UEK in use:# uname -r3.8.13-118.14.2.el7uek.x86_64

This is a non-UEK:# uname -r3.10.0-514.el7.x86_64

On Oracle UEK start with:#sudo yum install kernel-uek-devel.x86_64

On RHEL, CentOSor Oracle non-UEK start with:#sudo yum install "kernel-devel-uname-r == $(uname -r)"

The following process is the same for RHEL, CentOSand Oracle UEK/non-UEK.

If ZST was already installed in its non-DKMS version make a backup of its configuration and then remove the installed ZST:

# mkdir zst-config# cp -v /etc/zing/pmem.conf.* zst-config# sudo yum remove zing-zst

Now ZST for DKMS will be installed:

# sudo yum install yum-utils#sudo curl -O https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm#sudo yum cleanmetadatadbcache#sudo yum install epel-release-latest-7.noarch.rpm#sudo yum-config-manager --disable epel#sudo yum --enablerepo=epel install dkms

Afterwards, please download the Zing JVM RPM package and the Zing System Tools DKMS RPM packagefrom http://www.azul.com/downloads/software-downloads-and-documents.

Now those packages are installed:

#sudo yum installperl-Sys-Syslog.x86_64#sudo yum localinstall zing-zst-7d.dkms.2.6.18-5.15.0.0.3.el.x86_64.rpm#sudo yum localinstall zing-jdk1.8.0-16.01.7.0-6.x86_64.rpm

Now install the previously copied configuration and restart the Zing system service:

# sudo cp zst-config/pmem.conf.* /etc/zing/# sudo zing-memory restart

Afterwards, run the following commands to verify that ZST is completely installed and Zing is working:

# sudo service zing-memory status# /opt/zing/zing-jdk8/bin/java -version

On later Operating System updates triggered by rpm or yum, the dkms-based ZST will be rebuild automatically and no user interaction is necessary.

If for some reason, the dkms-based ZST has to be rebuild and reinstalled manually, please use the following commands, but replace the version numbers according to your system:

#sudo dkms statuszing_mm, 5.16.0.0-3, 4.4.0-53-generic, x86_64: installedzing_mm, 5.16.0.0-3, 4.4.0-59-generic, x86_64: installed#sudo dkms build zing_mm/5.16.0.0-3#sudo dkms install zing_mm/5.16.0.0-3

In case the EPEL mirrors cannot be reached on later upgrades, please reinstall the EPEL.rpm to receive the updated mirrors list:

# sudo curl -O https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm# sudo yum reinstall epel-release-latest-7.noarch.rpm

This page describes the installation using DKMS when Zing was manually downloaded from http://www.azul.com/downloads/software-downloads-and-documents.

If you are using the Zing Trial or install Zing from the repository, please visit instead Instructions for DKMS with Zing installed from the repository.

An important metric to monitor for many applications is the application response time, for others it is throughput or both combined. Those need to be measured from the outside with the perspective of the user. Many components and factors have an influence on those metrics and the JVM is only one of them, but an important one.

In addition monitoring the JVM, here in this article specifically Zing, helps to detect trends early, before the application metrics are affected.

Standard JVM Pausetime Logging

The following JVM standard command line options for monitoring application pauses caused by the GC and Safepoints are also usable on Zing. But on Zing no problematic pauses are expected as with its special GC algorithm the short synchronization steps for phase transitions inside the JVM are independent of the heap size and in most practical use cases are not exceeding single digit ms (1/1000 s). Here the standard JVM command line options for tracking application pauses caused by the JVM and at the same time track the time the application was running in parallel to GC activity:

-XX:+PrintGCApplicationConcurrentTime-XX:+PrintGCApplicationStoppedTimeThose are logged to the garbage collection log which is enabled by the following: -Xloggc:gc.log

Example entry in the gc.log of Zing or OpenJDK:

$ grep -E 'Application time:|Total time.*stopped' gc.log12.836: Application time: 0.6752136 seconds12.836: Total time for which application threads were stopped: 0.0000602 seconds, Stopping threads took: 0.0000074 seconds

Standard JVM JMX MBeans

If your monitoring system is already tracking the Java application heap utilization over JMX, for example to detect application memory leaks, the standard Java MXBeans like the following can be continued to be used on Zing:

java.lang.management.MemoryPoolMXBeanjava.lang.management.MemoryMXBean

As Zing's Garbage Collector always runs concurrently to the application, the application continues to allocate memory while the GC is running. That's a normal and desired behavior for any concurrent GC as it increases application performance. But it means on the monitoring side that you'll notice higher values on the MXBean attribute "used" on Zing than on other GCs which add pauses. But for detecting application memory leaks and long term trend analysis those metrics are still valuable. You might only need to increase the percentage of the warning threshold to avoid false alerts.

Additional note when enabling Zing's ZST component where the feature Contingency Memory is available by default: Under high memory pressure, the attribute value "used" can grow larger than 100% on Zing with ZST as there Contingency Memory is available to cover situations when applications temporarily need more heap than assigned by -Xmx. If your monitoring calculates percentages, that detail is important to avoid calculation errors or unintended negative values. Further details: onMemoryPoolMXBean the attribute "max" stays constant and equals -Xmx but on MemoryMXBean the attribute "max" will also grow above -Xmx when Contingency Memory is actively used under high memory pressure.

Zing Metrics from JMX MBeans

To monitor the CPU activity of Zing's concurrent GC in more detail over JMX or to view the stress on the GC, special MXBeans are available by adding the following command line option"

-XX:+UseZingMXBeans

The primarily interesting metrics there to monitor are the following:

PercentageOfTimeCollectorIsRunning: This is useful for analyzing the CPU activity caused by the GC and the stress on the GC. Setting a warning threshold when it exceeds 30% for more than 5 minutes is a good starting point. Occasional short spikes to 100% are not problematic.

PercentJavaHeapOccupiedAfterCollection: This is useful for analyzing the actual memory requirements of the application and to detect application memory leaks. Setting a warning threshold when it exceeds 70% for 5 minutes is a good starting point.

For more details regarding ZingMXBeans and its most important metrics please start reading in the section Monitoring the ZVM Using JMX and Zing MXBeans on the following page https://docs.azul.com/zing/ZingMXBeans.htm

Zing Metrics from GC.log

The same metrics offered over JMX are also available in Zing's garbage collection log file activated by adding the standard JDK parameter-Xloggc:gc.log. Zing includes the example script /opt/zing/zing-jdk8/etc/gcLogScraper to extract metrics from that log file.

Example usage to extract current heap utilization in MBytes (NewGen + OldGen + PermGen), CodeCache usage, Linux memory usage outside of the heap in kBytes and application thread delays:

$ gcLogScraper -l GC -c 'jvmuptime_s=%{end#end} curheap_MB=%{heap#cur} maxheap_MB=%{heap#max} codecache_MB=%{heap#codec} rss_kB=%{heap#rss} maxdelay_s=%{delay#max}' < gc_zing.logjvmuptime_s=29.701548 curheap_MB=6968 maxheap_MB=20480 codecache_MB=1 rss_kB=117817 maxdelay_s=-jvmuptime_s=34.316951 curheap_MB=8834 maxheap_MB=20480 codecache_MB=1 rss_kB=134111 maxdelay_s=0.000jvmuptime_s=36.048295 curheap_MB=9588 maxheap_MB=20480 codecache_MB=1 rss_kB=139652 maxdelay_s=0.000jvmuptime_s=38.341703 curheap_MB=10538 maxheap_MB=20480 codecache_MB=1 rss_kB=147521 maxdelay_s=0.000

Example usage to extract the percentage of time the concurrent GC is active in parallel to the application and the live Java objects in MBytes. Those are separately tracked for the NewGen and OldGen memory pools and GC threads:

$ gcLogScraper -l GC -c '%{end#end} %{type} %{intracycle#sec} %{intercycle#sec} %{heap#live}' < gc_zing.log | grep New | awk '{ printf("jvmuptime_ms=%d type=%s gctime_%=%.0f liveheap_MB=%d\n", $1 * 1000, $2, $3 / ($3 + $4) * 100, $5) }'jvmuptime_ms=62664 type=New gctime_%=44 liveheap_MB=4242jvmuptime_ms=65855 type=New gctime_%=33 liveheap_MB=4454jvmuptime_ms=67806 type=New gctime_%=38 liveheap_MB=4373

$ gcLogScraper -l GC -c '%{end#end} %{type} %{intracycle#sec} %{intercycle#sec} %{heap#live}' < gc_zing.log | grep Old | awk '{ printf("jvmuptime_ms=%d type=%s gctime_%=%.0f liveheap_MB=%d\n", $1 * 1000, $2, $3 / ($3 + $4) * 100, $5) }'jvmuptime_ms=21032 type=Old gctime_%=31 liveheap_MB=2043jvmuptime_ms=25274 type=Old gctime_%=28 liveheap_MB=1667jvmuptime_ms=29701 type=Old gctime_%=27 liveheap_MB=1599

Next to the GC another component of any JVM using CPU resources in parallel to the application is the JIT Compiler. The Zing log also records metrics about its activity. Here an example to track the number of active compiler threads per compiler tier and CPU time spend in JIT compilation:

$ gcLogScraper -l COMPSTATS -c 'jvmuptime_s=%{logtime} jitcomp_tier=%{Tier} jitcomp_activethreads=%{Active} jitcomp_cumulated_cputime_ms=%{CPUTime}' < gc_zing.logjvmuptime_s=12.939 jitcomp_tier=1 jitcomp_activethreads=0 jitcomp_cumulated_cputime_ms=129jvmuptime_s=12.939 jitcomp_tier=2 jitcomp_activethreads=3 jitcomp_cumulated_cputime_ms=17569jvmuptime_s=16.288 jitcomp_tier=1 jitcomp_activethreads=2 jitcomp_cumulated_cputime_ms=197jvmuptime_s=16.288 jitcomp_tier=1 jitcomp_activethreads=1 jitcomp_cumulated_cputime_ms=197jvmuptime_s=16.544 jitcomp_tier=1 jitcomp_activethreads=0 jitcomp_cumulated_cputime_ms=198jvmuptime_s=16.544 jitcomp_tier=2 jitcomp_activethreads=2 jitcomp_cumulated_cputime_ms=18923jvmuptime_s=21.036 jitcomp_tier=1 jitcomp_activethreads=0 jitcomp_cumulated_cputime_ms=245

Further details: https://docs.azul.com/zing/UsingZing_gcLogScraper_Overview.htm

What to do if Zing fails on startup with an error message like this:

ERROR: az_pmem_reserve_pages (num2mPages 193811)Fatal error: os::safeSystem: command '/usr/sbin/zing-llpmem --reserve --partition 0 --pages 193811 --nodemask 0xFFFFFFFF' failed.zing-memory: ERROR: Configure pmem failedFatal error: os::safeSystem: command '/etc/init.d/zing-memory restart' failed.

The most likely cause of this error is that there is not enough free RAM on the system, specifically, there are not enough free large pages (2MB or 4MB) for Zing to start up. This might be due to memory fragmentation.

Since Zing ZST 5.21.7 an optional configuration is available to resolve this situation. Please consider upgrading the Zing ZST component, available for download on https://www.azul.com/software-downloads-and-documents/ and if needed, enable the additional configuration as described on the following page: https://docs.azul.com/zing/ZingAppA_EnhancedLinuxMemoryDefragmentation.htm

Since ZVM 19.07 Zing can also be installed and used without ZST. In that mode it does not need large pages and uses standard 4k Linux pages instead and won't be affected by memory fragmentation.

On older ZST versions the fastest way to try to fix this is to reboot your machine.

Zulu and OpenJDK installation packages do not include any font files by default. But both automatically use available fonts provided by the Operating System as high quality TTF files.

On headless servers or small Linux installations like containers or embedded systems those operating system font packages are usually not installed by default. Here the commands to install them:

RHEL / Centos:

sudo yum install fontconfig dejavu-sans-fonts dejavu-serif-fonts

Ubuntu / Debian:

sudo apt install fonts-dejavu fontconfig

SLES:

sudo zypper install dejavu-fonts fontconfig

Desktop Operating Systems like Windows and macOS usually already have many fonts in TTF format already installed by default and don't require additional installations.

After installation of those font packages, Zulu will automatically use the TTF files provided by the packages. If an application asks for specific font names, like for example Lucida, the fontconfig package installed with the commands above provides a similar replacement font without the need for a change in the application code.

Here an example error message indicating that the installation commands listed above are needed:

Exception in thread "main" java.lang.Error: Probable fatal error:No fonts found. at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236) at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100)

An alternative or addition to using the Operating System Fonts is the separate Zulu Commercial Compatibility Kitwhich contains Lucida font files. Please refer for download and its terms of use on the following page: https://www.azul.com/products/zulu-and-zulu-enterprise/cck-downloads/

If you don't see such an error message but the font rendering appears to be low quality, please also follow the instructions listed above as some TTF files might be missing on the system. If after the installation the font rendering appears to be still unexpected, take a look at Font rendering changes after upgrading Zulu.

Zing supports Docker since ZVM 15.09.

Since ZVM 19.07 Zing does not need the ZST component any more which was required in earlier versions. To run Zing within a Container now you only need to install the ZVM tar.gz package inside the container. It is available for download at the tar.gz icon on the Zing quick start page.

For old ZVM versions before 19.07, here the instructions to use it with the ZST component:

As Zing consists oftwo components, the JVM itself (ZVM) and the Zing Systems Tools (ZST), one detail is important to note when using Zing on Docker:

In addition to the two installation packages ZVM and ZST a third one, the Container-ZST is required.

This Container-ZST is available on Zing Downloads for the licensed version of Zing in the section Docker Container.

Sample filename:zing-zst-7e.ForContainer-5.16.0.0.3.el5.x86_64.rpm

Installation Overview

Install the standard ZST package on the host operating system where you use the docker command to launch containers. As host OS you can use any of the support OS for ZST. The ZVM package is not needed on the host OS and you don't need a license file on the host OS.For installing ZST on the host OS, follow the documentation on Zing Installation Quick Start.If you are using CoreOS as host OS, please follow the Docs for Docker on CoreOS instead.

Add the following option to the start command (docker run ...) for your Docker container:--device /dev/zing_mm0:/dev/zing_mm0

Start theDocker container.

Install the Container-ZST package inside the container.

Install the standard ZVM package inside the container.

Install the Zing license file to /etc/zing/license inside the container.

Check for a successful installation by starting the Zing JVM inside the container:/opt/zing/zing-jdk-VERSION/bin/java -version

Documentation reference, contains information how to download the Container-ZST package: Zing Docker Quick Start

With using Zing for Cassandra you don't need to spend time in tuning the JVM Garbage Collection parameters.

Here a quick overview for switching from other JVMs to Zing on a Cassandra node:

The following documentation relies on Zing version ZVM 19.07 or newer as since this version Zing does not need the ZST component any more which was required in earlier versions. If you deploy a new Cassandra installation make sure that the ZST component is disabled or not installed by running the command "zing-ps -V". If it shows a version number, ZST is still active. If it returns "Zing-memory is stopped" or "command not found", ZST is disabled or not installed. ZST is now only an optional tuning for Zing and new installations should start without it as a wrong configuration of ZST can reduce performance with Java applications using much native memory outside of the Java heap as Cassandra does.

First, after stopping the Cassandra service on the node, install Zing. The fastest way is to start on the Zing quick start page using the Zing package repository. Then change the JVM setting for Cassandra:

JAVA_HOME=/opt/zing/zing-jdk8

That's all.You don't need to change any other JVM parameter in the cassandra-env.sh configuration. Zing is ignoring non-Zing -XX parameters which you might have added before to tune other GC implementations.

After restarting the Cassandra node you can check with the followingcommand if the switch to Zing was successful and the java command used is actually Zing and not a different JVM. A Zing java process returns "Zing 64-Bit Tiered VM" as version information.

jcmd JAVAPID VM.version

With JAVAPID the process ID of the java command as listed by just running "jcmd" without parameters.

For production systems, the following change is recommended:

Disable the Cassandra GCInspector log messages as it might report long running GC phases which are of no concern when using Zing as those logged times are phases of the GC which are runin parallel to the application and don't pause the application when using Zing. The log messages written to the Cassandra system.log are ofthe following pattern:INFO [Service Thread] DATE GCInspector.java:284 - GPGC New GC in 300ms. GenPauselessTo disable them, add the following line to cassandra_install_location/conf/logback.xml: <logger name="org.apache.cassandra.service.GCInspector" level="ERROR"/>

For further questions about Zing configuration or system performance, please ask Azul Support.

Cassandra on Zing was never affected by the following JDK bug as a fix in Zing was already included in the Zing releases around the time this bug was triggered by a change added with JDK 8u161 / 8u162: https://issues.apache.org/jira/browse/CASSANDRA-14173

If you see the following error message:

$ /usr/lib/jvm/zulu-8/bin/java -version-bash: java: No such file or directory

It is usually either caused by a missing Zulu JDK/JRE installation or by running a 32 bit executable on a pure 64 bit system. Check for the existence of the java executable first, as a wrong path to the JDK/JRE can also be a cause for this:

$ file /usr/lib/jvm/zulu-8/bin/javajava: ELF 32-bit LSB executable

If the file exists and shows a 32 bit executable and your operating system is 64 bit, there are two solutions:

a) Install the 32 bit libraries as operating system package ia32-libs.

b) Install a 64 bit Zulu JDK or JRE.

Short answer: No

Just change JAVA_HOME to/opt/zing/zing-jdk8 or PATH to /opt/zing/zing-jdk8/bin or your application specific setting to point to the Zing java executable at /opt/zing/zing-jdk8/bin/java.

In general Zing implements the entire Java Standard Edition standard. That means all fundamental command line parametersare supported per the relevant Java major level specification.

If an -XX command line parameter has no meaning in Zing (like for instance GC settings for G1 or CMS, which don't exist in Zing) then those variables are silently ignored. Many-XX parameters are implemented by Zing, for example -XX:+UseGCLogFileRotation.

With Zing it isn't expected that you need to tune or optimize any GC settings. The only parameter you might consider to change when switching to Zing is -Xmx as with Zing you are not limited to small heap sizes any more.

For a comprehensive review of Zing command line flags, review the topic Command-Line Options for the Zing Virtual Machine in the online Zing Documentation.

The Zing FAQ reflects common technical and business questions with answers regardingthe Zing product offering.

You can login to the Zing Community Forum to post questions on any suitable topic.

The technical support team at Azul routinely fields product questions. Contact usat [email protected].

For business or commercial questions of any kind, please contact [email protected].

Zing JVM can create Java Heap Dumps in the standard HPROF binary format. They are for instance triggeredby the included jmap command. For analyzing the heap dumps the included jhat or any other Java profiling tool capable of reading the HPROF format can be used.

One reason for using Heap Dumps is analyzing the memory usage withinyour application. As Zing offers with ZVision a built-in production-time non-intrusive CPU and memory profiling tool, you might not need to create those GByte-large heap dumps any more. Read more on Monitoring Tools included in Zing.

Zing includes a non-intrusive, production-time application profile and diagnose tool, called Zing Vision (ZVision). In contrast to most other existing external profiling or monitoring tools dedicated to Java applications, ZVision allows a fine-grained insight into the different components of your application without any noticeable overhead. This is possible as ZVision is built into the JVM itself and not just attached as Java Agent.

CPU usage per method, memory usage by objects and by classes isdisplayed, thread dumps and other internal data that helps to identify bottlenecks or high resource usage in the application.

The method used within ZVision to create thread dumps does not pause your application as externally triggered thread dumps do. For example if you create a thread dump with the jstack tool or kill -3 (SIGQUIT) the application is stopped until all threads reached a safepoint.

Read more about ZVision inthe ZVision Technical Info Overview and also in the Zing User Guide.

If you have replaced JAVA_HOME or the absolute path to the java executable and your application does not start, first run the following command to check if all necessary components for Zing, the JDK (ZVM), the Zing System Tools(ZST) and the /etc/zing/license file are installed completely:

/opt/zing/zing-jdk8/bin/java -version

If the test with "java -version" works fine, but your application not, then maybe the -Xmx settings for the maximum Java heap size was set too high. Zing supports up to 8 TByte heap size, but is of course practically limited by the free RAM your system provides. Please check the stdout and stderr log files of your application to identify the cause in detail.

Here an example for Tomcat:

# tail /var/log/tomcat8/catalina.outError occurred during initialization of VMMemory management: unable to fund java heap account

Setting -Xmx20G in JAVA_OPTS for Tomcat on this system with 30 GBytes RAM solved the issue.

To identify the maximum value for -Xmx of your system, use the following command:

zing-ps -s

The value at the column Reservable, line Free shows the maximum possible -Xmx value in MBytes.

Are you already installing the most recent Zing ZVM and ZST packages?

They are available for download on https://www.azul.com/software-downloads-and-documents/ and in addition they are available from the Zing package repository as documented in http://docs.azul.com/zing/index.htm#InstallZing.htm.

If you are not a customer, go to http://azul.com/zingtrial for receiving the most recent version.

To receive help for Zing installation issues or all other technical problems with Zing write to our support on [email protected]. Even if you are not a customer yet and have problems with the free Zing trial installation, please write to that address.

Also check the Zing documentation: http://docs.azul.com/zing

If your Hypervisor System is running on an intel Xeon CPUnewer than 2009 or AMD Opteron newer than 2010 it most likely already complies to the Zing Specifications. For more details go to ZingSystem requirements. At least 2 vCores are needed and adding more improves the throughput. As guest system on the hypervisor you can use any of the supported Linux distributions.

On the virtualization system the Balloon Driver should be switched off: How to disable the Balloon Driver

Zing on Docker is supported: Installing Zing on Docker

You can also install the standard Zing packages inside any HVM Linux-based AWS EC2 instance (but not on PV instances). Amazon Linux is preferred for that use case, but RHEL, Ubuntu, Debian or SLES can also be used. Read more about this on Zing on Amazon Linux. Installation on other cloud providers like Google or Azure is also possible as long as the guest OS system is one of the supported by Zing.

If you are not sure if your system is supported and don't won't to read through all those documentation, just go to https://azul.com/zingtrial, our automatic self service page, for downloading the Zing trial installation package. It offers the same functionality as the full version.

Yes. The standard way to install Zing is to use the package repository provided by Azul for the major Linux distributions. Go to the Zing Installation Instructions for details.

The free Zing Trial technically uses the same repository.

For registered customers, Azul also offers the Zing installation packages for individual downloads of current and all previous released Zing versions on Zing Software Downloads.

Zing JVM requires a valid non-expired license for launching Java applications.

The license is only checked during start of the Zing JVM process. That means the Zing JVM process will continue to run, even if it reaches through the expiration date and the hard-stop date.

As exact time for the expiration, the end of the day of the expiration date is used within the local timezone of the Zing JVM process.

Two dates are defining the license validity: The expiration date is the date writtenin the license contract between the customer and Azul. The hard-stop date is the date which technically limits the usability of the license. The hard-stop date allows to add some safety buffer after the expiration date to evade possible issues with falsetimezone calculations.

Since ZVM 18.07.0.0 the license is also checked when running just/opt/zing/zing-jdk8/bin/java -version

You can verify the integrity of the license and if it hasn't reached the expiration and hard-stop date with the zing-licensed command. Sample results:

Before the warning date:

# zing-licensed --verifyZing license '/etc/zing/license' verification is successful.

After reaching the warning date or expiration date:

# zing-licensed --verifyWarning: Your Zing license /etc/zing/license is about to expire on 2017-04-06 (YYYY-MM-DD).Warning: Please contact Azul Systems as soon as possible to renew your license.Zing license '/etc/zing/license' verification is successful.

After reaching the hard-stop date:

# zing-licensed --verifyERROR: Failed to verify Zing license '/etc/zing/license'ERROR: Your Zing license expired on 2017-04-06 (YYYY-MM-DD). Hard stop enforced. Please contact Azul Systems to renew your license

# zing-licensed --display[...]sublicense.date.timezone: LOCALsublicense.issued.date: 2017-01-06 14:02:21sublicense.warning.date: 2017-03-30 23:59:59sublicense.expires.date: 2017-04-06 23:59:59sublicense.hardstop.date: 2017-04-09 23:59:59[...]

Documentation reference: Installing Zing Standalone Licenses Azul Support 24/7 email or phone, for contacting about any license issue: http://www.azul.com/support

If your system uses an x86 64bit Intel Xeon CPU built after 2009 or an AMD Opteron CPU built after 2010 it is most likely compatible. For details see Zing System Requirements Documentation. At least 7.5 GByte of RAM is recommended.

Zing can take easily advantage of more RAM with its pauseless Zing GC as it is not limited by long Full GC pauses which you might have seen when increasing the -Xmx with your current JVM in use. Up to 8 TByte RAM (8192 GByte) is supported by Zing and can be used as value for the -Xmx parameter.

This article will be of interest to you if you are seeing messages like this in a logfile, or printed to stdErr for your process:

Detected TTSP issue: start: 31.259 wait: 17.526 Dumping stack for thread 0x0000440005e00000 "Thread-1" id: 30703 prio: 5 os_prio: 0 sched: SCHED_OTHER allowed_cpus: 000000000ffffff lock_release: 31.276 last_cpu: 20 cpu_time: 17563 0 0x00000000209f41d5 SafepointProfilerBuf::record_sync_stack(JavaThread*) 1 0x0000000020a35d68 JavaThread::safepoint_profiler_record_sync_stack()

These messages are not Errors. They are produced by a mechanism in theZing Virtual Machine (ZVM) called the Safepoint Profiler. Thishelps you work out what's happening in your application when there are threads that take longer than a given threshold to reach a safepoint.The Safepoint Profiler is designed to have a minimal impact on your application, and Azul Support recommends that you keep it on so that you have the information you need to help diagnose time to safepoint issues if they occur.

When the ZVM needs to bring all running threads to a safepoint in order to perform some critical task, it notifies all the threads. Sometimes one or moreof thethreads will take longer than others torespond to the notification, and then the threads which responded to the request in a timely fashion are delayed.

What the Safepoint Profiler messages show you is the stacks for the late threads, and you can examine the stacks towork out what could be making the thread late to safepoint, and then take action to correct it in future.

There is a set of flags that you can use to control the Safepoint Profiler:

-XX:+SafepointWaitTimeProfiler

This is the flag that controls the turning on and off whole profiling mechanism. It's on by default: use -XX:-SafepointWaitTimeProfiler to turn it off.

-XX:SafepointWaitTimeProfilerLog=<logfile>

By default the profiling information is logged onto the stderr, this flag redirects the output to a file.

-XX:SafepointProfilerThreshold=n

This is a threshold in percentage of safepoint/ checkpoint that controls when to activate profiling. So, for the curretly default value of SafepointTimoutDelay 50000, we would start profiling the threads once we cross 1000 ms (2% of timeout). The default value of this flag is 2.

-XX:SafepointProfilerInterval=n

This is the interval in percentage of safepoint/ checkpoint that controls the frequency at which you would like to collect multiple stack samples for a TTSP issue. The default value of this flag is 1.

For more information on safepoint profiling, including a more detailed overview and advice on how to read the output, please consult the Safepoint Profiler section of the Zing User Guide.

Zing is available in Java SE levels 8.0, 7.0 and 6.0 which corresponds to the OpenJDK internal version scheme 1.8.0, 1.7.0 and 1.6.0.

For most use cases, you only need to knowthe required Java SE level for your application to decide which Zing version to install.

If your application documentation for instance lists Java 1.7.0_131 as requirement, you need to downloadthe latest ZVM version of Java SE level 7.0 from the Zing download page. Please note, that in addition to the ZVM package you also need to downloadthe ZST package on the same page.

If an application documentation emphasizes a requirement to a specific Java SE update level within one of those three SE levels, like 8u111 (1.8.0_111) with the focus on the 111, the reason for that might bea security fix or a bugfix specifically addressing a Java SE API method usedby the application.

The Zing Release Notes contain information about security fixes which were adopted from OpenJDK into Zingto address a known CVE. Major bugfixes regarding Java SE API methods are also listed. If that information is not sufficient and you need more information about the corresponding Java SE update level of the Zing version you are using, please contact Azul Customer Support.

Theversion numbering scheme for Zing (ZVM)follows the numbering scheme used for Ubuntu Linux. For example Zing version 15.05.1.0 denotes with the first two numbers the major version, here 15.05, where 15 stands for the year 2015 and 05 for the month of May. The 3rdand 4th numbers are the minor version, 1.0 in this example. The version numbering of ZST (Zing System Tools) is independent from ZVM and Java SE. Generally, all previousZVM versions can be run on the latest ZST. If you already have an ZST installed and need to find out if that older version is compatible with a ZVM version, take a look at the Zing ZST-ZVM Version Compatibility table.

This article presumes you have experimented with Zing on your own using the Zing free trial or otherwise have determined Zing would work with your applications, but have not yet contactedAzul.

You can directly buy small number of one year host-based licenses on the following page over Paypal: Order Zing by Credit Card

For long term licenses and larger volumes of licenses please reach out to [email protected] or complete the request form for generic Azul inquiries. An on-site trial is different from a self-guided trial because it typically involves you working closely with Azul to qualify Zing against your evaluation criteria. Azul wants to help youmeet all yourbusiness justifications, in addition to ensuring a technical fit.

If you are an open source developer, academic researcher or other qualified participants, take a look at the Zing Open Source Developer program.

Many presales materials, Zing product datasheets, and service and support offerings areenumeratedhere and should provide all you need to research Zing for your use cases.

Still unsure? Email [email protected] and Azul will help figure out your needs.

Zing follows the naming conventions specified in the article " System Properties and the java -version Command," from which this article borrows terminology.

The output of the java -version command includes a product version identifier and a build indentifier. This output is determined by the values of several system properties, and those system properties can themselves be examined programmatically at runtime.

The output reflects the settings of two system properties as follows:java.version. Line one displays the product version.java.runtime.version. Line one displays the product version. Line two displays the build identifier.

Example: Zing output from java -version

java version "1.8.0-zing_16.07.0.0"Zing Runtime Environment for Java Applications (build 1.8.0-zing_16.07.0.0-b4)Zing 64-Bit Tiered VM (build 1.8.0-zing_16.07.0.0-b17-product-azlinuxM-X86_64, mixed mode)

The parts of the version number "1.8.0-zing_16.07.0.0" consist of the Java SE major level, the name zing, and the Azul version number, in major.minor.maintenance.patch notation.

With Zing System Tools (ZST) 5.20.5, Zing provides compatibility with the newly available Linux fixes for the recently reported Intel CPU kernel side-channel security flaws known as Spectre and Meltdown.

ZST 5.20.5 (or newer) is required for Zing to operate on Linux distributions that have been updated to address these flaws with the addition of KPTI (kernel page table isolation).

Without upgrading ZST, the new Linux kernel KPTI fix will prevent Zing from working and the Operating System and kernel will crash when the first Zing java application is launched or just the following command is run:/opt/zing/zing-jdk8/bin/java -version

In that case you might see the following messages or similar on the Linux console / dmesg:

# fatal error: az_mremap() failed

azmm: assert failed ... av_vmemCall trace: az_vmem_exit_mm

The solution is to upgrade to ZST 5.20.5 or higher as soon as possible if you are running Zing on RHEL, CentOS, Oracle Linux, SLES 12, Ubuntu, Debian or Amazon Linux. For SLES 11 you need ZST 5.20.6 or higher.

Upgrading ZVM, the other Zing component, is not necessary for the KPTI fix.

ZST Download page: https://www.azul.com/downloads/software-downloads-and-documents/

ZST Upgrade instructions: http://docs.azul.com/zing/UpgradingZingSystemTools.htm

If you are working on a test or developer system with the Zing trial, just use "yum update" or equivalent commands on your Linux distribution to upgrade the ZST package.

In addition to the ZST upgrade, please run the following command to verify if it lists "pcid":

grep -i pcid /proc/cpuinfo | head -1

PCID (process-context identifier) is a CPU feature which increases performance when running with the KPTI fix. Zing will work without PCID, but PCID is preferred for Zing.

If it does not list "pcid" and you are running on a virtual machine or a cloud service, then please check the hypervisor documentation whether PCID it can be enabled. On cloud services relaunch the instance or start a newer instance type as it might be already included in upgraded instances.

PCID on VMware

See the description above, why it should be enabled on VMware systems running Zing.Documentation from VMware about the KPTI fix and recommendation to upgrade the VM guests to virtual hardware version 11: https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html PCID is enabled on VMware since virtual hardware version 11: https://kb.vmware.com/s/article/52085

If one of the following exceptions is thrown in your application while trying to use strong encryption with key lengths of more than 128 bits, the causefor this is most likely a missing Java Cryptography Extension (JCE):

java.security.InvalidKeyException: Illegal key size

Cryptographic key type aes256-cts-hmac-sha1-96 not found

Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled

For Zing ZVM 17.x.x.x and older, the solution is to install the Zulu Cryptography Extension Kit (Zulu CEK). Zing and Zulu ship with strong encryption, though limited to key lengths of up to 128 bit in earlier versions. The Zulu CEK provides an upgrade to 'unlimited' key sizes. After installing the Zulu CEK, you can use for example AES 256 bits for https, SSL/TLS, Kerberos or other applications of encryption.

The Zulu CEK is compatible to Java SE 6, 7 and 8 on Zing and Zulu.

ZIP for download and installation documentation: https://www.azul.com/products/zulu-and-zulu-enterprise/zulu-cryptography-extension-kit/

For Zing ZVM 18.x.x.x and newer no configuration or installation of JCE is necessary any more as the unlimited encryption is enabled by default. Zing follows the OpenJDK strategy here which changed to this setting with 8u161. If your application requires the limited policy for compatibility reasons, you can switch back to it by either adding the line crypto.policy=limited to /opt/zing/zing-jdk8/jre/lib/security/java.security or adding the line Security.setProperty("crypto.policy", "limited") to your code.

For Zing ZVM 17.11.x.x and 17.12.x.x, all the above solutions are usable to facilitate the transition. The only difference towards ZVM 18.x.x.x and newer is the default setting, which is limited on 17.11 and 17.12 as it was with OpenJDK 8u152.

This article is applicable only to jHiccup v2.x. The jHiccup 2.x distro comes with two helper apps to help you analyze and visualize jHiccup's output. They are:

jHiccupLogProcessor jHiccupPlotter.xls

It's a two step process.

1. Use jHiccupLogProcessor to convert the jHiccup log file to human readable output files.2. Use jHiccupPlotter.xls to visualize the data in the jHiccupLogProcessor output files.

Step 1: jHiccupLogProcessor

jHiccup logs hiccup information in a histogram log (see HdrHistogram.org). This histogram log contains a full, high fidelity histogram of all collected result sin each interval, in a highly compressed form (typically using only ~200-400 bytes per interval). However, other than the timestamp and maximum hiccup magnitude found in the given interval, the rest of the log line for each interval is not human readable (it is a base64 encoding of a compressed HdrHistogram).

To translate the jHiccup log file to a more human-readable form (identical to the form that jHiccup versions before jHiccup 2.0 had used), the jHiccupLogProcessor utility is provided. Here's a simple example:

% jHiccupLogProcessor -i jHiccup.log -o jHiccup.log.out

That example will produce two log files: jHiccup.log.out and jHiccup.log.out.hgrm. The first file, jHiccup.log.out, will contain a human readable interval log, with selected percentiles in each interval. The second file, jHiccup.log.out.hgrm, will contain a human readable histogram percentile distribution log.

Step 2: jHiccupPlotter.xls

Use jHiccupPlotter.xls to visualize the data in the files produced by jHiccupLogProcessor produced. The spreadsheet reads both of the jHiccupLogProcessor output files,

Click the Enable Content button if you get "SECURITY WARNING Some active content has been disabled." when you open the file.

Click the Open File icon in the Main Menu worksheet and point it to the jHiccupLogProcessor interval log. The spreadsheet needs both of the jHiccupLogProcessor output files, so both files must be in the same directory.

Click Go and the spreadsheet will create a new worksheet with a graph of your jHiccup results.

More Information

For more information about jHiccup and these tools please see the README file in the jHiccup 2.x distro. You can download the current version of jHiccup (v 2.0.6 as of this writing) from the Azul Systems website.

Zing is a fully certified Java SE implementation and can support all Java workloads.

All versions of Zing undergo rigorous QA testing, including a battery of Java unit tests called the Java Technology Compatibility Kit (TCK) for Java SE. The Technology Compatibility Kit is licensed by only a handful of JVM vendors, and of those, only a few including Azul, have the right to claim certification for all three versions of Java currently covered by the TCK, Java 6, 7, and 8.

Above and beyond the TCK certification tests the Azul QA team runs hundredsof open and closed source test suites with third party software stacks including WebLogic, JBoss, Hadoop, and many others, in order to ensure that Zing can support all of the Java workloads our customers demand.