1.Is generational ZGC fully implemented in version 21 of openjdk? Or is it partially realized?
2.What is the main difference between generational ZGC and ordinary ZGC?
Ordinary ZGC: collect all objects every time Generational ZGC: Recycling by generation We believe that Generational ZGC will be better suited for most use cases than its predecessor. Some workloads may even see throughput improvements with generational ZGC due to lower resource usage. For example, when running the Apache Cassandra benchmark, generational ZGC required a quarter the heap size but achieved four times the throughput compared to non-generational ZGC, while still keeping pause times under one millisecond. .
Some workloads are non-generational in nature and may experience slight performance degradation. We believe this is a small enough set of workloads to justify the cost of maintaining two separate versions of ZGC over the long term.
Another source of overhead is the more powerful GC barrier. We expect much of this to be offset by the benefit of not having to collect old generation objects as frequently.
Another source of additional overhead is running two garbage collectors simultaneously. We need to make sure to balance their call rate and CPU consumption so that they don’t impact the application unduly.
As is normal with GC development, future improvements and optimizations will be driven by benchmarking and user feedback. We intend to continue improving Generational ZGC even after the first version is released.
3.During the development process of OpenJDK by generation ZGC, their development time span, R&D personnel and other information. The main purpose is to have an estimate of the approximate effort of this work.
3.1.JDK21-Schedule
Schedule
2023/06/08 Rampdown Phase One (fork from main line-JDK17-LTS)
2023/07/20 Rampdown Phase Two
2023/08/10 Initial Release Candidate
2023/08/24 Final Release Candidate
2023/09/19 General Availability
Amost 103days
3.2.Generational ZGC-R&D staff
Co-authored-by: Stefan Karlsson
Co-authored-by: Erik Österlund
Co-authored-by: Axel Boldt-Christmas
Co-authored-by: Per Liden
Co-authored-by: Stefan Johansson
Co-authored-by: Albert Mingkun Yang
Co-authored-by: Erik Helin
Co-authored-by: Roberto Castañeda Lozano
Co-authored-by: Nils Eliasson
Co-authored-by: Martin Doerr
Co-authored-by: Leslie Zhai
Co-authored-by: Fei Yang
Co-authored-by: Yadong Wang
Reviewed-by: eosterlund, aboldtch, rcastanedalo
13人
3.3.Generational ZGC-workload
3.3.1.Functional scope
- No multi-mapped memory
- Optimized barriers
2. 1.Fast paths and slow paths
2. 2.Minimizing load barrier responsibilities
2. 3.Double-buffered remembered sets
2. 4.Remembered-set barriers
2. 5.SATB marking barriers
2. 6.Fused store barrier checks
2. 7.Store barrier buffers
2. 8.Barrier patching - Relocations without additional heap memory
- Dense heap regions
- Large objects
- Full garbage collections
3.3.2.Amount of code
Showing 667 changed files with 63,137 additions and 7,698 deletions.
4.Is it possible to backport this function to java17?
4.1.Throughput
In terms of throughput, generational ZGC improves by about 10% over single-generation ZGC in JDK 17 and a little over 10% over single-generation ZGC in JDK 21, which dropped slightly.
4.2.Latency
The average latency of generational ZGC decreases slightly compared to single-generation ZGC.
ZGC starts to perform well when maximum pause times are considered. The graph below shows a 10-20% improvement in P99 pause time.
The biggest advantage of generational ZGC is that it significantly reduces the biggest problem of single-generation ZGC - the possibility of allocation stagnation. Allocation stagnation means that new objects are allocated faster than the ZGC can reclaim memory.
5.Verification scenario
5.1.Multi-client concurrency
This problem can be seen if we switch the use case to Apache Cassandra and look at 99.999%. The graph below shows that up to 75 concurrent clients, single-generation ZGC and multi-generation ZGC have similar performance. However, with more than 75 concurrent clients, the single-generation ZGC becomes overwhelmed and encounters allocation stagnation issues. Generational ZGC, on the other hand, did not encounter this situation and maintained consistent pause times even with up to 275 concurrent clients.
5.2.P99.99 Event
Requires that 99.99% of requests should be faster than the given latency. In other words, only 0.01% of requests are allowed to be slowed down. Much like the old run, single-generation ZGC performed very well under low load, but as allocation pressure increased, worse latencies increased. With Generational ZGC, this is no longer the case. p99.99 latency is very low even under heavy load.
