Back to Zing Documentation Home
This section summarizes issues known in Zing.
Large Amounts of Virtual Memory Shown by top and ps for Zing Java Processes
Linux tools like
ps, etc. show large amounts of virtual memory address space for all Zing Java processes in the range of several TBytes. This is an expected and normal behavior as Zing utilizes a large address space for its GC algorithm. It will not take away memory resources from other processes as the memory itself is not used, just the large address space is needed.
Unexpected Resident Set Size Memory Metric Shown by top and ps for Zing Java Processes
For the Zing Virtual Machine without the Zing System Tools (ZST) component (the default mode of Zing), the Linux
ps, and other tools overestimate the memory use of Zing Java processes. As a result, resident set sizes (RSS, RES) of more than 3 times the
-Xmx value display. The reason for this is Zing's usage of virtual memory multi-maps, i.e., multiple references to the same physical memory locations. To get precise metrics for the actual memory utilization, run the Linux
smem -P java command which shows the memory usage in the PSS (proportional set size) column. The Linux
free command shows correct summary metrics.
For Zing with the installed Zing System Tools component, the memory metric resident set size (RSS, RES) does not include the memory used for the Java heap and thereby shows an unexpectedly small value of only a few hundred MBytes even when you set multiple GBytes of
-Xmx. The reason for this is the dedicated memory management by the ZST. For performance reasons, ZST handles the memory for Java heaps independently from Linux default memory management. Only the total amount of memory used for Java heaps is visible by standard Linux tools like, for example, shown with the
free command. To list the heap memory usage for Zing java processes when ZST is installed, use the
zing-ps -s command. With that, the heap memory, managed by the ZST, is shown in the Xmx column, the small amount of Linx RSS - in the LRSS column, and the memory used by Zing internally and managed by the ZST - in the ZRSS column.
Also on Zing with the installed ZST, a similar effect is visible regarding the Linux metric Mlocked in
/proc/meminfo. While the ZST-managed memory is protected from being swapped out, similar to a Linux mlock, it is not visible as Mlocked in
Version-Specific Known Issues
The following table lists issues known
ZVM crash is seen when there is a mismatch between ZST versions on a host and containers.
Workaround: Ensure ZST versions on a host and containers match. Also, note that since ZVM 19.07.0.0, Zing does not need the ZST component which was required in earlier versions of Zing. Starting with ZVM 19.07.0.0, install only a ZVM package inside your container to run Zing within a container.
Heap dumps and JVMTI object tagging are not supported with
The combination of the
Test failure due to code cache exhaustion on configurations with heaps of 4 GB and below are more likely to happen on ZVM 220.127.116.11 as the default CodeCache size progressively shrinks for such configurations.
Workaround: Increase the code cache size using the
When used in -XX:-UseZST mode, applications that allocate significant amounts of large (multi-MB) objects at high rates and on a sustained basis may observe higher than normal time to safepoint behaviors.
When Zing is used in the Non-ZST mode, the RSS/RES value reported by such Linux tools as
Zing License Verification failed when
Workaround: Clean up the
Zing 11 JFR events refer to null
The Live Objects ZMC representation does not show anything for Zing 11 JFR recordings as the JFR Leak Profiler is not yet enabled in Zing 11 JFR and the OldObjectSample event is not generated.
|Zing releases from 17.08.0.0 to 19.03.0.0||
If you have
In Java 11 testing, a rare ZVM 18.12 crash was observed when returning from the invocation of a MethodHandle routine. Analysis revealed the failure to be reproducible under rare circumstances in Java 8 with previous ZVM releases. Frequency of reproduction appears to be influenced by use of ReadyNow! with Java 11. It is recommended that users of ReadyNow! do not upgrade to Java 11 until this issue is resolved.
Handshake messages can be strictly ordered.
Workaround: Use alpn-boot-8.1.13.v20181017.jar.
|18.09.0.0||When run on ZST 5.21.x and older, ZVM 18.09.0.0 cannot tick-profile native threads.|
|18.06.0.0||ZVM 18.06.0.0 can crash when
In 18.03.0.0 and 18.03.1.0, the combination of ReadyNow!, compile stashing (enabled by default with ReadyNow!), and a profile which is fed from one run to another in a rolling manner can in some circumstances result in severe peak performance loss. If using ReadyNow! with a rolling profile on 18.03.0.0 or 18.03.1.0, it is strongly recommended to upgrade to 18.03.2.0, 18.04.0.0, or a later release which include fixes for this issue. If a peak performance problem is observed, we recommend discarding the profile collected with 18.03.0.0 or 18.03.1.0 and recollecting a fresh one on an unaffected version.
WebSphere fails to launch when using
|all Zing releases||
Loop predicate and loop limit check code problem.
(1) The java spec says explicitly that operations on integers can overflow and no exception will be thrown. Indeed, unlike the C++ spec that says integer overflow is undefined, java says integer overflow is required to happen.
(2) Java coding guidelines always point out that using Integer.
(2a) This loop will terminate because eventually i will be equal to Integer.
(2b) This loop will never terminate, because i will overflow:
(3) Zing will sometimes terminate the loop in (2b).
JBoss7 throws an exception on startup with -
ZVM running in environment with multiple scheduling policies, RR, BATCH, and OTHER, encounters checkpoint sync timeout in thread running with BATCH policy.
- Zing Virtual Machine Release Notes
- Common Vulnerabilities and Exposures Fixes
- Features Added in Previous Releases
- Issues Resolved in Previous Releases
Last modified: September 30, 2020
© Azul Systems, Inc. 2020 All rights reserved.