3

新GraalVM免费版本开放了一些收费功能

 1 year ago
source link: https://www.jdon.com/66933.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

新GraalVM免费版本开放了一些收费功能

GraalVM(Java VM)刚刚发布了一个新的发行版--免费提供了一些商业版本的功能。这意味着-您现在可以在生产环境中免费使用这些GraalVM功能! 太棒了!

新的发行版Oracle GraalVM,适用于JDK 17和JDK 20,并在GraalVM免费条款和条件(GFTC)许可下发布(也见FAQ)。这意味着你可以免费使用所有最伟大的GraalVM商业收费功能,无论是用于开发还是用于生产!

对于Native Image原生镜像,在这个版本中,我们将引入:

  • 配置文件指导下的优化和更多的编译器优化,以获得最佳的峰值性能
  • G1 GC用于运行具有大堆和最小暂停时间的应用程序
  • 压缩对象头和指针,以达到更低的内存占用率
  • 机器学习,自动推断剖析信息
  • 支持SBOM的额外安全功能

GraalVM Native Image已经因其即时启动而闻名,但通过这个版本,我们可以证明,它也是一种令人难以置信的高效方式,可以高性能地运行长期运行的Java应用程序。

我们在一个用GeralVM Native Image编译的Java 20 Spring PetClinic示例应用程序上测试了我们的版本,并与JIT编译进行了比较,其性能优势如下:

Native Image原生镜像以最快的应用程序启动时间而闻名。由于有了Oracle GraalVM的额外编译器优化,启动速度更上一层楼:

  • 与GraalVM CE Native Image相比,Oracle GraalVM Native Image的启动速度提高了46.42%。
  • 与在JIT上运行相比,启动速度快32倍(GraalVM CE与C2 JIT)。

由于额外的内存优化,我们用Oracle GraalVM Native Image构建的基准应用程序使用的内存明显减少:

  • 比使用GraalVM CE Native Image少25%的内存
  • 比使用C2 JIT的GraalVM CE少2.52倍的内存!

Oracle GraalVM Native Image的峰值吞吐量比GraalVM CE高1.6倍。对于这个特定的应用,吞吐量仍然略低于JIT。当用Spring以及Quarkus和Micronaut运行其他基准时,在许多情况下,我们看到AOT的峰值吞吐量甚至超过了JIT。

对你的应用程序进行评估的另一个重要指标是效率:在给定的时间和资源下,你能获得多少性能。这与云计算特别相关,在那里你为资源和你使用它们的时间付费,但即使在内部,你也想有效地使用你的基础设施。

Oracle GraalVM Native Image可以处理14780个请求/GB/s,是CE Native Image和C2 JIT的两倍。

这意味着使用Oracle GraalVM Native Image,你可以为你所拥有的基础设施获得最佳的峰值吞吐量,或者即使在资源有限的环境中也能以良好的性能运行。

现在让我们来看看延迟情况。
延迟是一个重要的指标,反映了你的应用程序的所有请求的响应能力。最慢的请求在尾部延迟分布中可见,并对服务质量产生很大影响。通常情况下,业务需求对大多数请求规定了特定的延迟限制(通常是99%,即P99延迟)。

Oracle GraalVM Native Image和CE JIT与C2的响应时间非常相似,都在3ms以下。
这意味着你可以期望你的应用程序在Native Image和JIT上有同样的响应能力。
然而,在JIT上最高的百分位数明显下降,而在Native Image上则保持较低的水平。所以对于这个应用来说,Native Image提供了一个明显更好的P99延迟,从而改善了服务的响应性。

总之,Oracle GraalVM Native Image除了快速启动和低资源使用外,还为长期运行的应用程序提供了出色的性能特征。

适用于JDK 17和JDK 20的GraalVM
GraalVM现在有一个新的命名方案,与JDK的版本划分相一致--例如,这个版本包括两个GraalVM版本:GraalVM for JDK 17 和 GraalVM for JDK 20。这两个版本都是基于主分支的,都包含新的功能,所以你可以选择最适合你的JDK版本。

不过,我们鼓励你转到JDK 20--正如我们前段时间宣布的那样,我们正在过渡到一个新的发布时间表,我们将只为最新的Java版本发布GraalVM(就像Oracle JDK那样)。这样一来,你也可以同时使用所有最新的Java和GraalVM功能。

这个版本的另一个伟大的更新是,GraalVM JDK的下载现在包括了Native Image!不需要将Native Image作为一个单独的组件下载,也不需要运行gu install native-image,它从一开始就已经准备好了。

下载Oracle GraalVM也变得更容易了--我们现在有了稳定的可编写脚本的下载URL,所以你可以直接使用它们来下载,或者在你的脚本和Docker文件中使用。例如,要在Linux x86-64上获得适用于JDK 20的Oracle GraalVM,请运行以下命令:

wget https://download.oracle.com/graalvm/20/latest/graalvm-jdk-20_linux-x64_bin.tar.gz

用于编译器优化的机器学习
Oracle GraalVM中的一个非常有用的功能是剖析引导的优化(PGO)。PGO使你能够在运行时收集应用程序的剖析信息,然后与Native Image一起使用,以优化生成的本地可执行文件的性能。它使你能够结合两个世界的优点:AOT优化和运行时剖析的力量。

这个版本中令人激动的新功能之一是基于机器学习的配置文件推断。Native Image现在使用一个预先训练好的ML模型来预测控制流图分支的概率。然后,我们使用预测的概率来执行PGO。在我们对Renaissance、Da Capo和Da Capo con Scala等综合基准的测量中,与默认的Native Image配置相比,由预测的配置文件驱动的PGO提供了6%的运行时速度提升。基于ML的配置文件推断在Oracle GraalVM中是可用的,默认情况下是启用的,我们期待着您的反馈和性能报告。

然而,请记住,ML配置文件推断可能会使本地可执行文件的大小略微增加1-2%。

原生镜像中更多的性能
编译器可以提供更好的性能,其中一个方法是利用你的部署平台的特定架构功能。使用这些特定的功能对性能是很好的,但在没有这些特定指令的机器上部署时,可能会带来兼容性的挑战。我们引入了一个新的-march选项,类似于gcc,让你可以在特定平台的性能和兼容性之间灵活选择:-march=compatibility可以获得最佳的兼容性,或者-march=native可以获得最佳的性能,如果本地可执行文件被部署在相同的机器架构上或具有相同CPU特性的机器上。要列出所有可用的机器架构,使用-march=list。

我们还对配置文件引导的优化做了一些改变:

  • 为了给您的应用程序提供最佳的峰值性能,PGO必须拥有其完整的剖析信息。这意味着您可能需要在不同的工作负载下多次运行您的应用程序,以确保对其所有的使用情况进行分析。现在,在PGO多次运行中收集的剖析信息可以与本地镜像配置合并。
  • 剖析引导的优化现在有一个新的采样剖析器,可以收集调用堆栈。这些数据会被包含在一个.iprof文件中。构建PGO指导下的可执行文件时,默认开启采样分析器(但必要时可以禁用)。请记住,为了获得良好的剖析,从而获得良好的峰值性能,你需要运行相关的工作负载并适当预热你的应用程序。
  • 我们还实施了一个上下文感知的inliner优化,它使用新的采样剖析器来更好地将优化努力投入到热代码中。其结果是,可执行文件的大小减少了2-7%,峰值性能有所提高。
  • 我们改进了对Native Image的循环矢量化支持,使编译器能够矢量化更多的循环以加快执行速度,并使AOT中某些代码形状的性能与JIT相当。

原生镜像包
Native Image原生镜像 构建命令 (native-image -jar MyApp.jar) 表面上看起来很简单,但它启动了一个复杂的构建过程,其中有许多取决于环境的变量和属性。能够复制一个构建过程是非常有帮助的--例如,用于更新和修补你的应用程序,或者重现问题。为了这个目的,这个版本引入了本地镜像包。

现在你可以生成一个构建包,其中包含你的应用程序的JAR文件,以及参数、环境变量、系统属性设置、classpath和模块路径选项等信息。

要产生一个捆绑包,在构建本地可执行文件时使用 - bundle-create=<imagename>.nib 标志。
这将产生实际的可执行文件,就像以前一样,还有一个<imagename>.nib文件和<imagename>.output目录。

有了这些文件,你就可以通过运行以下程序来复制构建:

native-image -bundle-apply=.../path/to/<imagename>.nib

捆绑程序应该可以简化更新Native Image的部署,并有助于调试和重现问题。

原生镜像Native Image的开发者体验
每一次发布,我们都会引入更新,使开发者在使用GraalVM,特别是Native Image时的体验更加流畅和精简。在这个版本中,有几个变化:

  • 改进了Native Image构建过程中的内存占用率。构建器现在考虑到了可用的内存,以减少在同一台机器上运行许多其他进程时的内存压力。在许多情况下,它消耗的内存也更少,因此也更不可能因内存不足的错误而失败。同时,我们增加了Native Image可以使用的最大内存量,这将有助于构建大型应用程序。
  • 对我们的Windows用户来说是个好消息!Native Image现在可以自动为Windows设置构建环境--你不再需要使用x64 Native Tools命令提示符。我们还改进了在Windows上的调试:调试信息现在包括Java类型的信息。
  • 我们继续建立我们的JFR支持。现在也支持以下事件:ExecutionSample、ObjectAllocationInNewTLAB和JavaMonitorInflate。
  • 我们致力于使元数据构成安全,这样添加新的元数据就不会破坏构建。
  • 内部错误变得更加用户友好。在失败的情况下,Native Image的构建不再只是显示堆栈跟踪,而是提供一个错误报告和如何报告这个问题的说明。
  • 现在可以通过LLVM后端在RISC-V上使用GraalVM Native Image了

原生镜像的新监控功能 
应广大用户的要求,我们和社区一起通过JMX实现了远程管理。

​​​​​​​它可以通过 --enable-monitoring选项启用,例如: --enable-monitoring=jmxclient,jmxserver。

注意,这个功能是试验性的。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK