1.分代ZGC 是否在openjdk的21版本里面完全实现？还是部分实现？

完全实现

2.分代ZGC和普通的ZGC的主要区别在哪里？

普通的ZGC：每次回收所有对象 分代ZGC：分代进行回收 我们相信，Generational ZGC 将比其前身更适合大多数用例。 由于资源使用率较低，某些工作负载甚至可能会通过分代 ZGC 获得吞吐量提升。 例如，当运行 Apache Cassandra 基准测试时，与非分代 ZGC 相比，分代 ZGC 需要四分之一的堆大小，但却实现了四倍的吞吐量，同时仍将暂停时间保持在一毫秒以下。

某些工作负载本质上是非分代的，并且可能会出现轻微的性能下降。 我们认为，这是一组足够小的工作负载，不足以证明长期维护两个单独版本的 ZGC 的成本是合理的。

另一种开销来源是功能更强大的 GC 屏障。 我们预计其中大部分将被不必频繁收集老一代对象的收益所抵消。

另一个额外的开销来源是同时运行两个垃圾收集器。 我们需要确保平衡它们的调用率和 CPU 消耗，以便它们不会过度影响应用程序。

正如 GC 开发的正常情况一样，未来的改进和优化将由基准测试和用户反馈驱动。 即使在第一个版本发布之后，我们也打算继续改进 Generational ZGC。

3.分代ZGC在OpenJDK的开发过程中，他们开发的时间跨度，研发人员等等信息。主要目的是希望能对这个工作的大概effort有一个评估。

3.1.JDK21-日程

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.分代ZGC-研发人员


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.分代ZGC-工作量

3.3.1.功能范围

JEPS439

  1. 非多重映射内存
  2. 屏障优化
    2. 1.快路径和慢路径
    2. 2.最大限度地减少负载屏障的责任
    2. 3.双缓冲记忆集
    2. 4.记忆设置的屏障
    2. 5.SATB 标记屏障
    2. 6.融合存储屏障检查
    2. 7.存储屏障缓冲区
    2. 8.修补屏障
  3. 无需额外堆内存的重定位
  4. 密集堆区
  5. 大对象
  6. 完整的垃圾收集

3.3.2.代码量

Showing 667 changed files with 63,137 additions and 7,698 deletions.

4.Backport这个功能到java17的可行性？

4.1.吞吐量


就吞吐量而言，分代 ZGC 比 JDK 17 中的单代 ZGC 提高了约 10%，比 JDK 21 中的单代 ZGC 提高了 10% 多一点，而 JDK 21 中的单代 ZGC 略有下降。

4.2.延迟

与单代 ZGC 相比，分代 ZGC 的平均延迟略有下降。

当考虑最大暂停时间时，ZGC 开始表现出色。下图显示 P99 暂停时间提高了 10-20%。

分代ZGC最大的优势是，它显著降低了单代ZGC所存在的最大问题——分配停滞的可能性。分配停滞是指新对象分配的速率快于ZGC回收内存的速率。

5.验证场景

5.1.多客户端并发

如果我们将用例切换到ApacheCassandra并查看99.999%，就可以看出这个问题。下图显示，多达75个并发客户端，单代ZGC和多代ZGC具有相似的性能。然而，超过75个并发客户端，单代ZGC会不堪重负，并遇到分配停滞问题。另一方面，Generational ZGC没有遇到这种情况，即使有多达275个并发客户端，也能保持一致的暂停时间。

5.2.P99.99 Event

要求99.99% 的请求应该比给定的延迟更快。换句话说，只允许 0.01% 的请求变慢。与旧的运行非常相似，单代ZGC在低负载下表现非常好，但随着分配压力的增加，更糟糕的延迟也会增加。对于Generational ZGC，情况已不再如此。即使在高负载下，p99.99延迟也非常低。