Kieran France Kieran France is a programmer for IDRSolutions in charge of there internal test suite. In his spare time he enjoys tinkering with gadgets and code.

Improved Garbage Collection in Java 13

1 min read

The JVM has several Garbage Collectors available that you are able to specify, each with its own advantages. In Java 11 the Z Garbage Collector was introduced and now with Java 13 further improvements to this Garbage Collector have been introduced.


What is the Z Garbage Collector

The Z Garbage Collector (ZGC) is an optional Garbage Collector (GC) added as of JDK 11 for Linux/x64. This GC aims to keep pause time to below 10ms whilst handling heaps of any size.
The heap for the ZGC when it was first introduced would allow memory usage to be allocated but not deallocated. This means the amount of allocated memory would increase but never decrease. If your application requires more memory on start up than during continued operation the application would hold on to more memory than required.

This is the reason for JEP-351 being added to JDK 13.


JEP-351: ZGC: Uncommit Unused Memory

As detailed above, the ZGC could not uncommit allocated memory back to the operating system before JEP-351.
With the introduction of JPED-351 the ZGC will be able to uncommit memory so it is available for the operating system again.
The ZGC consists of a set of heap regions called ZPages, each containing variable amounts of memory. When ZPages are freed they are added to a page cache ready for reuse.
These cached pages are not currently used in the application can could be uncommitted.
In this version the ZGC would use a simple time out policy to determine when a ZPage is uncommitted but more sophisticated poloicies could be introduced in the future.
As of this version for the OpenJDK, support for Linux/AArch64 has also been included.


What benefits does this have?

These improvements have several obvious benefits on preformance of an application as we keep ensure our memory allocation is limited to what we actually need.
This would be even more beneficial in Container environments where resources are limited or there is a fee involved based on resources used.
In environments where an application may become idel and others continue running the ZGC can free up more memory for other applications.
It should be noted that this functionality already exists in G1 and Shenandoah GCs, adding it to ZGC makes it much more effective for many users.

IDRsolutions develop a Java PDF Viewer and SDK, an Adobe forms to HTML5 forms converter, a PDF to HTML5 converter and a Java ImageIO replacement. On the blog our team post anything interesting they learn about.

Kieran France Kieran France is a programmer for IDRSolutions in charge of there internal test suite. In his spare time he enjoys tinkering with gadgets and code.

Java 13 Articles-series index

Here at IDRsolutions we always like to research and test the key new features in each Java release, as well as some of the hidden...
28 sec read

Why we wrote our own Java jpeg2000 libraries

JPEG2000 is an important image file format which offers significant benefits over JPEG. For our specific usage it does generate significantly smaller file sizes...
Mark Stephens
52 sec read

How to choose JPG versus JPEG2000 for image files

Since we started to support both JPG and JPG2000 as image file outputs in our software, we have found that this is a very...
Mark Stephens
1 min read

Leave a Reply

Your email address will not be published. Required fields are marked *

IDRsolutions Ltd 2019. All rights reserved.