云原生编译：将JVM带入现代云世界

最新推荐文章于 2024-06-11 14:33:13 发布

码出星海

最新推荐文章于 2024-06-11 14:33:13 发布

阅读量858

点赞数

文章标签：云原生 java cloud native

本文链接：https://blog.csdn.net/m0_67455745/article/details/123443087

版权

随着Java的不断成熟，重要的是推动云优化功能，以提供更好的性能和更低的成本。

在整个行业中，公司都在试图控制失控的云成本通过从云中运行的实例中挤出更多的承载能力。尤其是在Java领域，开发人员正试图将工作负载放入越来越小的实例中，并以最高效率利用服务器资源。依靠弹性水平伸缩来处理流量峰值意味着Java工作负载必须快速启动并保持快速。但是有些过时了JVM的特性很难有效地利用云实例上的资源。

是时候重新想象Java如何在以云为中心的世界中运行了。我们从探索如何通过将JIT工作负载卸载到云资源来优化编译开始。我们能否获得性能更高、预热时间更短的优化代码？

在这篇博客中，我们将关注:

当前JIT编译模型的起源
基于JVM的JIT编译的缺点
云原生编译如何影响性能、预热时间和计算资源

JIT编译的回顾

今天的Java JIT编译模型可以追溯到20世纪90年代。自20世纪90年代以来，很多事情都发生了变化！但是有些东西，比如Java JIT编译模型，却没有。我们可以做得更好。

首先，回顾一下JIT编译。当JVM启动时，它在较慢的解释器中运行Java程序中编译好的可移植字节码，直到它能够识别“热”方法的概要以及它们是如何运行的。然后，JIT编译器将这些方法编译成机器码，这些机器码针对当前的使用模式进行了高度优化。它运行代码，直到优化结果是错误的。在这种情况下，我们得到一个去优化，其中优化的代码被抛出，方法在解释器中再次运行，直到产生一个新的优化方法。当JVM关闭时，所有的概要文件信息和优化的方法都被丢弃，在下一次运行时，整个过程从头开始。

当Java在90年代被创造出来的时候，还没有像“魔法云”这样的东西，它是由相互连接的、有弹性的资源组成的，我们可以随意上下旋转。因此，使JVM(包括JIT编译器)完全封装和独立是一个合乎逻辑的选择。

那么这种方法的缺点是什么呢？嗯…

JIT编译器必须与执行应用程序逻辑的线程共享资源。这意味着有多少资源可以用于优化的限制，限制了这些优化的速度和有效性。例如，Azul Platform Prime的Falcon JIT编译器的最高优化级别可以在单个方法和工作负载上产生快50%-200%的代码。然而，在资源受限的机器上，由于资源限制，这样高的优化级别可能是不实际的。
您只需要在程序生命的一小部分时间里使用JIT编译资源。然而，对于on-JVM JIT编译，您必须永远保留容量。
在JVM生命周期的开始阶段，与JIT相关的CPU和内存使用的爆发会对负载平衡器、Kubernetes CPU节流和部署拓扑的其他部分造成严重破坏。
JVM没有过去运行的记忆。即使一个JVM正在运行一个它已经运行了一百次的工作负载，它也必须在解释器中从头开始运行它，就像是第一次运行一样。
JVM不知道运行相同程序的其他节点。每个JVM都基于其流量构建一个概要文件，但是一个更高性能的概要文件可以通过聚集数百个运行相同代码的JVM的经验来构建。

将JIT编译卸载到云

今天，我们确实有一个“神奇的资源云”,可以用来卸载JVM进程，这些进程可以在其他地方更有效地完成。这就是为什么我们构建了Cloud Native Compiler，可伸缩JIT编译资源的专用服务，您可以使用它来预热您的JVM。

云原生编译器作为Kubernetes集群在您的服务器上运行，无论是在本地还是在云中。因为它是可伸缩的，所以您可以在需要的时候提升服务，在短时间内为JIT编译提供几乎无限的资源，然后在不需要的时候将其降低到接近零。

在Java工作负载上使用云原生编译时:

客户端上的CPU消耗保持较低且稳定。您不必保留进行JIT编译的能力，并且可以调整实例的大小，以调整运行应用程序逻辑的资源需求。
无论JVM客户机实例的容量如何，您都可以运行最激进的优化，从而获得最高的性能。
由于更多的可用线程，JIT编译请求更多地并行运行，预热JVM的挂钟时间显著减少。

所以，真的有区别吗？

请注意，当我们在资源极其有限的2 vCore机器上运行finagle-http Renaissance工作负载时会发生什么。进行更重的优化意味着花费更多的资源，正如Azul Platform Prime与本地JIT的漫长预热曲线所示。当进行云原生编译时，这一漫长的预热时间与OpenJDK相同，而优化的Falcon代码继续以更快的吞吐量运行。