Posts

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人...

1.对比测试 1.1.测试环境 笔记本（3.1 GHz Intel Core i5, 4Gb RAM and 50Gb SSD.） 操作系统内核（3.10.0-1160.102.1.el7.x86_64） 操作系统（CentOS:7.9 VM） 平台: x86_64 VM Parameters：除存放和加载镜像日志的参数外，没使用其它参数 2.测试场景 2.1.场景一：Time Of First Operation 2.1.1.问题1：为什么Azul Prime ReadyNow相对于CRaC第二次启动会出现加速幅度降低？ 2.2.场景二：Time To Complete 100000 Operations 2.2.1.问题2：为什么Azul Prime ReadyNow相对于CRaC在100000笔请求延迟降低会比CRaC好？ 3.补充材料 3.1.CRaC是Azul主导贡献到OpenJDK社区的 常理上讲，Azul Prime ReadyNow作为Azul商业收费版应该比开源CRaC更好。 3.1.1.问题3：Azul Prime ReadyNow的安装包是不是正确的？ 3.1.2.问题4：验证所使用的用例是不是正确的？ 4.问题分析 4.1.问题1：为什么Azul Prime ReadyNow相对于CRaC第二次启动会出现加速幅度降低？ 4.1.1.猜测：串/并行文件处理导致的 4.1.1.1.CRaC用于恢复的文件结构-多文件组成 4.1.1.1.1.第一次启动截图-2.762秒完成启动 4.1.1.1.2.第二次启动截图-进程级恢复（进程ID一致） 4.1.1.2.ReadyNow用于恢复的文件结构-单文件组成 4.1.1.2.1.第一次启动截图-4.678秒完成启动 4.1.1.2.2.第二次启动截图-RootAC(提速16.2%)、APP（提速64.9%） 4.1.1.3.总结 1.单从文件加载效率角度分析，并行文件加载应该比串行文件处理效率高 2.借鉴ReadyNow的方案时，可将用于恢复的文件分割为多文件进行处理，验证是否可进一步优化第二次启动时间？[a.下一步可考虑的工作] 4.2.问题2：为什么Azul Prime ReadyNow相对于CRaC在100000笔请求延迟降低会比CRaC好？ 4.2.1.ReadyNow有JVM优化-Falcon JIT Compiler，而CRaC本质上没有优化JVM 4.2.1.1.CRaC-Hotspot VM CRaC本身没有优化JVM。 4.2.1.2.ReadyNow-Zing VM 将C2替换为Azul自研的Falcon JIT Compiler。...

1.场景视图 2.逻辑视图 注：29个类，不包含C的源码 3.开发视图 4.处理视图 4.1.启动应用 4.2.测试和调优 4.3.检查点生成 注：CRaC默认生成检查点镜像时会自动停止正在运行Java应用，但如Azul Prime ReadyNow、Spring-boot等支持按照周期等其它规则实现生成检查点镜像的同时不停止正在运行的Java应用，此功能也可用于生产环境。 4.4.恢复 4.物理视图 略。

0.前言 0.1.Java程序执行过程 0.2.编译的快与慢 0.2.1.Java虚拟机（解释的（Interpreted）相对慢） 0.2.2.即时编译器（Just In Time Compiler）（相对快） 0.2.3.Java编译器（Java Compiler）（相对快） Eg: Graal编译器（既可以作为AOT编译器，又可以在JIT编译器中替换C2）、AOT（jaotc） 1.JIT编译过程 Java应用启动后，在完成类加载、字节码验证后，并不会马上触发JIT编译器进行编译，而是先由即时解释器进行解释和分析； 即时解释器在完成了初步的解释和分析后，JIT编译器会利用已经收集到的分析信息来查找热点（经常执行的代码部分），有了热点代码后，C1就可以对这些热点代码进行分析，基于分析的结果编译生成相对高效的目标机器代码，从而使得此时的Java虚拟机具有本机的代码性能，于此同时C1也会进行进一步的分析； C1在完成了进一步的分析后，C2就会利用C1产生的分析信息，进行更积极、更耗时的优化，此时C2会重新编译代码，以生成更高效的目标机器代码，从而更明显的提升Java虚拟机的代码性能。 综上所述，基于热点的更多信息，C1 性能提升更快，而 C2 性能提升更好。 2.当前需求 Azul可以在模拟环境下预热（模拟出热点方法和循环体），然后将结果注入生产环境，直接使用 C2 编译，减少运行时的编译时间。这对于证券行业报盘等场景很有效，因为这些场景一开始就需要高速运转。 横轴：JVM虚拟机达到最佳代码性能的时间； 纵轴：JVM最佳代码性能程度或比率； 毛刺：去优化和垃圾回收导致的。 3.问题 Azul可以在模拟环境中学习和训练，然后将训练结果集作为参考输入到生产环境中，以达到启动时的峰值效果。 并消除 GC毛刺。 3.1.当前问题 启动时间长； 需要很长时间Java虚拟机才可以达到Java虚拟机的最佳代码性能。 3.2.期望结果 启动时间短； 启动后Java虚拟机可快速达到最佳代码性能。 3.3.期望目标 在保证关键功能正确使用的前提下，显著降低再次启动耗时； 消除毛刺，使得Java虚拟机快速达到最佳代码性能。 4.问题分析 4.1.现在加速启动的方案有哪些？ 4.1.1.CDS（Class Data Sharing,类数据共享） 功能定位： 将内部类、应用类、动态（自定义类加载器加载的类和省去dump classlist步骤）等表示转储到文件中（类加载器、jsa文件）； 在每个 JVM 启动时共享 (CDS)。 不足： 没有优化或热点检测； 仅减少类加载时间； 启动速度加快不明显。 4.1.2.AOT（Ahead Of Time Compilation，提前编译，源码到机器码） 优点： 从一开始就“全速”，GraalVM 原生镜像可以做到这一点; 根据定义，AOT 是静态的，代码在运行之前进行编译，运行时编译代码没有开销； 内存占用小 不足： 不解释字节码； 没有热点分析； 没有代码的运行时编译，所以没有运行时字节码生成； 方法内联的有限使用； 反射是可能的，但很复杂； 无法使用推测性优化 （假设条件成立，如数组边界） 必须针对共同特征（如同名同参数等）进行编译 由于优化不彻底，所以总体性能通常会较低； 部署环境！=开发环境。...