Using Shenandoah garbage collector with Red Hat build of OpenJDK 17
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation
We appreciate your feedback on our documentation. To provide feedback, you can highlight the text in a document and add comments.
This section explains how to submit feedback.
- You are logged in to the Red Hat Customer Portal.
- In the Red Hat Customer Portal, view the document in Multi-page HTML format.
To provide your feedback, perform the following steps:
Click the Feedback button in the top-right corner of the document to see existing feedback.Note
The feedback feature is enabled only in the Multi-page HTML format.
- Highlight the section of the document where you want to provide feedback.
Click the Add Feedback pop-up that appears near the highlighted text.
A text box appears in the feedback section on the right side of the page.
Enter your feedback in the text box and click Submit.
A documentation issue is created.
- To view the issue, click the issue tracker link in the feedback view.
Chapter 1. Shenandoah garbage collector
Shenandoah is the low pause time garbage collector (GC) that reduces GC pause times by performing more garbage collection work concurrently with the running Java program. Concurrent Mark Sweep garbage collector (CMS) and G1, default garbage collector for Red Hat build of OpenJDK 17 perform concurrent marking of live objects.
Shenandoah adds concurrent compaction. Shenandoah also reduces GC pause times by compacting objects concurrently with running Java threads. Pause times with Shenandoah are independent of the heap size, meaning you will have consistent pause time whether your heap is 200 MB or 200 GB. Shenandoah is an algorithm for applications which require responsiveness and predictable short pauses.
- For more information about the Shenandoah garbage collector, see Shenandoah GC in the Oracle OpenJDK documentation.
Chapter 2. Running Java applications with Shenandoah garbage collector
You can run your Java application with the Shenandoah garbage collector (GC).
- Installed Red Hat build of OpenJDK. See Installing Red Hat build of OpenJDK 17 on Red Hat Enterprise Linux in the Installing and using Red Hat build of OpenJDK 17 on RHEL guide.
Run your Java application with Shenandoah GC by using -XX:+UseShenandoahGC JVM option.
$ java <PATH_TO_YOUR_APPLICATION> -XX:+UseShenandoahGC
Chapter 3. Shenandoah garbage collector modes
You can run Shenandoah in three different modes. Select a specific mode with the -XX:ShenandoahGCMode=<name>. The following list describes each Shenandoah mode:
- normal/satb (product, default)
- This mode runs a concurrent garbage collector (GC) with Snapshot-At-The-Beginning (SATB) marking. This marking mode does the similar work as G1, the default garbage collector for Red Hat build of OpenJDK 17.
- iu (experimental)
- This mode runs a concurrent GC with Incremental Update (IU) marking. It can reclaim unreachably memory more aggressively. This marking mode mirrors the SATB mode. This may make marking less conservative, especially around accessing weak references.
- passive (diagnostic)
- This mode runs Stop the World Event GCs. This mode is used for functional testing, but sometimes it is useful for bisecting performance anomalies with GC barriers, or to ascertain the actual live data size in the application.
Chapter 4. Basic configuration options of Shenandoah garbage collector
Shenandoah garbage collector (GC) has the following basic configuration options:
- Print the individual GC timing.
- Print the heuristics decisions, which might shed light on outliers, if any.
Print the summary table on Shenandoah internal timings at the end of the run.
It is best to run this with logging enabled. This summary table conveys important information about GC performance. Heuristics logs are useful to figure out GC outliers.
- Commit heap pages into memory and helps to reduce latency hiccups.
- -Xms and -Xmx
Making the heap non-resizeable with
-Xms = -Xmxreduces difficulties with heap management. Along with
-Xms = -Xmxcommit all memory on startup, which avoids difficulties when memory is finally used.
-Xmsalso defines the low boundary for memory uncommit, so with
-Xms = -Xmxall memory stays committed. If you want to configure Shenandoah for a lower footprint, then setting lower
-Xmsis recommended. You need to decide how low to set it to balance the commit/uncommit overhead versus memory footprint. In many cases, you can set
Enables huge pages transparently. With transparent huge pages, it is recommended to set
madvise. When running with
AlwaysPreTouch, it will also pay the
defragtool costs upfront at startup.
While Shenandoah does not support NUMA explicitly yet, it is a good idea to enable NUMA interleaving on multi-socket hosts. Coupled with
AlwaysPreTouch, it provides better performance than the default out-of-the-box configuration.
- There is a tradeoff between uncontended (biased) locking throughput, and the safepoints JVM does to enable and disable them. For latency-oriented workloads, turn biased locking off.
- Invoking System.gc() from user code forces Shenandoah to perform additional GC cycle. It usually does not harm, as -XX:+ExplicitGCInvokesConcurrent gets enabled by default, which means the concurrent GC cycle would be invoked, not the STW Full GC.
Revised on 2023-08-15 12:23:39 UTC