Pause-Reduced Garbage Collection for Java
Abstract
z/VM 6.4 with APAR VM65987 lets Java exploit the new Guarded Storage Facility (GSF) for pause-reduced garbage collection (GC) on the IBM z14. The GSF is a new architecture that provides hardware-assisted read barriers for guarded storage involved in garbage collection. This feature lets application threads run concurrently during most garbage collection events, reducing the pause times during garbage collection.
Applications that exploit the GSF can experience a significant improvement in response time. A Java application running on Linux on z/VM experienced a 67% improvement in throughput for response time-constrained Service Level Agreements (SLAs).
Introduction
Garbage collection is critical for managing memory for the Java Virtual Machine (JVM). When the Java heap is full, garbage collection frees up objects that are no longer being referenced and relocates them within the heap. However, during this process the JVM will suspend all application threads to ensure the integrity of the live objects while they are being relocated in the heap. The amount of time the application threads are stopped while the objects are being relocated is called pause time. Pause time can have a significant impact on the performance of the application, especially if the application uses a large heap. Long pause times can cause response time SLA violations and application failures. With the GSF for the z14, the JVM can validate live objects while the application thread is running during most garbage collection events and therefore reduce pause time.
Requirements
- IBM z14 Guarded Storage Facility
- IBM Java 8 SR5
- JVM option: -Xgc:concurrentScavenge
- z/VM 6.4 with APAR VM65987
- Linux exploitation for guarded storage is not yet available.
Method
Workload details:
- Processor type and model: 3906-M05
- Dedicated LPAR, sixteen IFL cores, non-SMT mode.
- 1 TB central storage
- No other LPARs activated during the measurement.
- z/VM 6.4 with APAR VM65987
- One Linux guest running a Java Store Inventory and Point of Sale application
- The guest had sixteen virtual processors and 100 GB of virtual storage.
- IBM-internal Fedora Linux driver that exploits the Guarded Storage Facility
- IBM Java 8 SR5
- Heap size of 30 GB with a 16 GB nursery
The RSBASE runs are without the Guarded Storage. RSGSCS runs exploit guarded storage. Each run takes approximately two hours. Monitor data was collected for the entire run. Some variation in z/VM performance data was expected due to the length of the run and nature of the workload. Max throughput is the maximum steady state throughput achieved during the run. Response time-constrained throughput measures transactions which satisfy certain response time-constrained SLAs.
Results
| Table 1. Pause-Reduced GC Results | ||||
| Run ID | RSBASE0 | RSGSCS0 | Delta | Pct |
| Resp. Constrained Tx/sec | 12072 | 20210 | 8138 | 67.4 |
| Max Tx/sec | 47334 | 44883 | -2451 | -5.2 |
| Avg. Pause time (ms) | 221 | 32 | -189 | -85.5 |
| Pct. GC Running | 5.1 | 1.7 | -3.4 | -66.7 |
| CPUMF Inst/tx | 806426 | 820220 | 13794 | 1.7 |
| Tx per CPU-sec | 5401.57 | 5229.29 | -172.28 | -3.2 |
| T/V ratio (p) | 1.00 | 1.00 | 0.00 | 0.0 |
| Avg spin time | 1.70 | 1.68 | -0.02 | -1.3 |
| DASD I/O rate (p) | 101 | 102 | 1 | 1.0 |
| Notes: See method section for workload details. Avg. Pause Time is the average pause time for a GC event in milliseconds. Pct. GC Running is the percentage of total workload time that GC is running. | ||||
Results Highlights
- We saw improvement in response time with the Guarded Storage run. Response time-constrained throughput improved 67% in the Guarded Storage runs.
- There is a degradation in ETR (max tx/sec, 5%). ETR was expected to degrade slightly. The goal was to improve response time.
- z/VM performance data is fairly consistent for the runs, especially considering the expected variation due to the behavior of the workload. This workload is better suited to measure response time rather than overall system performance, but there was not a difference in z/VM behavior with guarded storage.
- The average duration for GC in the Guarded Storage run was 32 ms compared to 221 ms in the base run.
Summary
Java workloads running on Linux on z/VM can now take advantage of the Guarded Storage Facility to reduce pause times during garbage collection events. Shorter pause times can improve response time of transactions as well as reduce application timeouts or errors caused by garbage collection events. Our workload experienced a 67% improvement in response time-constrained thoughput. However, the impact of the reduced pause times is dependent on the workload. Workloads that run garbage collection more often will experience a more significant improvement.