GraalVM 了解一下？

Erich Ferdinand的《GraalVM》，在CC by 2.0许可下出版。最重要的是，有一个名为Twitter的旗舰项目。他们使用GraalVM已经有一段时间了。他们在Graal上运行Scala微服务。

GraalVM也来到了一个更加保守的商业世界。它似乎对云本地应用程序特别有吸引力。想想Lambda函数吧。所以是时候重温GraalVM了。是时候抛弃旧的Java虚拟机，转向新的东西了吗？

流行语

让我们看看我的合著者Karine创造的定义：

GraalVM是一个通用虚拟机，运行用JavaScript、Python、Ruby、R等语言编写的应用程序。它还支持C语言和C++语言。GraalVM使用LLVM编译器运行任何语言。这甚至包括FORTRAN。更不用说整个Java世界，包括Scala、Kotlin和（猜猜看！）Java本身。GraalVM承诺在不同编程语言之间实现真正的互操作性。也许我们很快就会看到使用虚拟机公共实例的多语言应用程序。还有更多。GraalVM也可以在嵌入式模式下运行，如Oracle数据库和MySQL所示。

哇！那可真是太难咽了。GraalVM为你准备了很多东西。

让我们逐一检查一下。那需要一段时间。本文是对一个由八部分组成的系列文章的高级介绍。九个部分，如果你算上我们12月份关于块菌的文章。我们甚至还没有开始讨论数据库。这很吸引人，但我们不确定是否希望在数据库中传播Java编程。在微服务和云本机应用程序时代，这似乎不是一个最佳实践。尽管如此，这是一个强大的工具，所以我们可能会很快探索它。

首先，Graal是Oracle实验室主持的一个研究项目。自2012年以来，开发团队已经发表了60多篇关于GraalVM的论文。所以我们问题的第一个答案是：GraalVM只是一个非常长期的学术项目。一个成功的，在那。

它的大部分内容都围绕着Futumara项目，使其成为一个真实而有用的东西。这就是我们上面提到的Truffle引擎。而Truffle则是GraalVM的多品种部分。它是JavaScript、Ruby、R和所有LLVM语言的领域。如果你像我一样，你以前从未听说过LLVM。稍微简化一下，LLVM是C/C++、FORTRAN等语言的虚拟机。LLVM编译器将C代码转换为LLVM位代码，该位代码在GraalVM上运行，无需进一步ado。

换句话说，如果您能够获得DOOM的源代码，就可以在javavm上玩这个游戏。由于版权的原因，很难获得这些源代码。这将是一个迷人的项目。我（Stephan）深深地记得Daniel Kurka传奇般的JavaScript演示文稿，它曾经包含一个JavaScript端口。当时，他的团队使用emscripten将C源代码翻译成JavaScript。我希望看到GraalVM重复这一成就，这样我们就能够比较这两种方法。我的猜测是：使用emscripten是一种痛苦的过程，GraalVM和LLVM可以从中解脱出来。

你注意到我们的语言列表没有包括Java吗？这不是一个错误。Truffle是用Java编写的，但它不是用来运行Java的。

但是GraalVM宇宙中有一个令人兴奋的项目就是这样做的。它被称为Espresso，出于某种原因，博客圈很少谈论它。所以我不确定这个项目是否还活着。但如果是这样，如果它能成功，Java将成为Truffle世界中的一流公民。简单地说：Espresso是一个真正多语言世界的承诺。它承诺我们可以从JavaScript、Ruby、R和所有其他受Truffle支持的语言调用Java。我们不认为这包括LLVM语言，但也许只是——也许，它也可以提供一个C++的API来调用java。

GraalVM作为JVM的插件替代品

还有GraalVM项目的另一部分。这一部分目前激起了更多的兴奋。GraalVM是Java虚拟机的插件替代品，运行Java、Scala、Kotlin和所有其他在Java字节码上运行的语言。自2019年以来，GraalVM已在Linux上投入生产。版本20.1.0还声称完全支持Windows。因此，我们可以对测试提出更高的要求。我们将在本系列的第三部分中这样做。

人们经常声称GraalVM具有卓越的性能。例如，Ruby的GraalVM实现的运行速度比原始实现快30倍，至少根据https://www.youtube.com/watch?v=iXCVaQzXi5w&t=715s 及https://www.youtube.com/watch?v=GinNxS3OSi0&t=726s. 就是这样。我们不知道这些信息有多可靠。我们已经测试了几个案例：JavaScript、Ruby和Java。

Ruby确实是一个惊喜。GraalVM运行合成Ruby基准测试的速度比Ruby 2.7.0快30%。当然，还有另外两个Ruby实现，我们还没有对它们进行测试。尽管如此，30%是一个有希望的开始。另外，我们肯定还有改进的空间。

从Java程序员的角度来看，事情更为实际。一般来说，GRAALVM的性能与Oracle的热点编译器大致相同。不错，但也没那么激动人心。当你读到这篇文章时，情况可能已经有所改善——我们正在谈论GraalVM 20.1.0。从长远来看，我们肯定GraalVM将围绕传统JVM运行。但这不会在短期内发生。Java是优化程度最高的编程语言之一，而且它仍在进行优化，因此击败它是一项艰巨的任务。我们相信这是可能的，因为GraalVM是一种全新的产品，它不需要承担20多年优化的负担。目前，GRAALVM的源代码非常直接，至少与C++ JVM的源代码相比。至少，这是我们被告知的，也是我们乐观的动力。

JavaScript也是如此。如果你相信这次会议的内容，GraalVM目前运行JavaScript程序的速度与Google的V8编译器相同，不管有多少余量。这是一个了不起的成就，但如果你是一名经理，就没什么好激动的了。我们还必须认识到，如果你是一名开发人员，那没什么好激动的。当我们运行测试时，我们了解到只有少数JavaScript程序达到这种性能水平。这些程序存在，我们已经看到了。但许多其他应用程序的运行速度为10%。特别是，GraalVM 20.1.0上的Angular CLI速度非常慢。

平心而论，Angular CLI的工作完美无瑕给我们留下了深刻印象。它需要node.js的整个生态系统。GraalVM附带node.js和npm的工作副本。更好的是，它与ECMAScript 2019兼容。即使今天的速度可能很慢，这也是一个了不起的成就。此外，项目团队已经宣布了一个大胆的目标：他们希望达到与node.js提供的相同的最高性能。

作为技术人员，我们对此印象深刻。不管我们怎么努力，我们都做不到！我们不会因为缺乏自尊而痛苦。就是这样。但所有这些技术优势都无法说服您的首席执行官在Graal上运行您的应用程序。如果GraalVM要成为一种东西，它必须证明它的价值。

尽管如此，Graal还是引起了媒体的广泛关注。GraalVM成功背后的驱动因素是什么？

驱动因素：性能和可维护性

关键驱动因素之一是GraalVM的卓越性能。当然，在Java或JavaScript的情况下，这不是一个小交易。我们相信（或希望？）这种情况很快就会改变。GraalVM是一个开源项目，用流行语言编写。现在，每个人和他们的祖母都能流利地讲Java，因此很容易为GraalVM捐款。好吧，也许这有点夸张，但是改进热点编译器要容易得多。请注意HotSpot编译器肩负着二十年的历史。雪上加霜的是，HotSpot编译器是用C/C++编写的，这是一种仍然流行的语言，但在Java程序员中并不流行。

用Java重写JVM编译器打开了一个新的机会之窗。可以打赌的是，无数Java程序员将花一些时间使用GraalVM，发现一些弱点，并对错误进行修复和改进。GraalVM年轻的年龄让他在公园里散步。相比之下，V8引擎和HotSpot编译器都经历了数十年的优化。我们被告知，在不破坏其他东西的情况下改进任何东西都不容易。如果您已经使用过大型企业应用程序，那么您就知道问题所在。在商业世界中，微服务起到了拯救作用。在JVM世界中，它是GraalVM。基于新的想法，这是对旧问题的一种新的看法。另外，它的编写考虑到了优化和扩展。

这可能就是Twitter采用GraalVM的原因。他们正在Scala上运行生产代码。这是一种编译到JVM字节码的语言。太糟糕了，字节码是专门为Java开发的。Scala引入了与Java字节码不完全匹配的新概念。当然，Twitter仍然使用相同的字节码，但他们已经用Scala特定的优化对GraalVM进行了调整。

Ruby和R的情况更为明显。这些语言不是JVM语言。当然，还有JRuby项目编译成Java字节码。这是一个非常成功的项目。然而，JRuby的总体实现从不同的角度解决了这个问题。它是一个运行在Truffle框架上的解释器，这是Futumara项目的一个实现。

Truffe-未来预测成真

这是一种编写编译器的聪明方法，可以省去编写编译器的麻烦。简言之，其思想是，一旦您的基础语言使用了一个实时优化编译器，它就会编译并优化所有内容。如果您编写一个解释器，这个解释器也会由即时编译器编译和优化。如果您和编译器都很聪明，那么解释器运行应用程序的速度就和编写传统编译器一样快。只是简单多了。每个人和奶奶都会写翻译。编写一个好的编译器是一门艺术。

这种方法的优点在于它既是一个解释器，又是他们所说的编译器。在预热阶段之后，Graal将Ruby编译成与手工优化的汇编代码相当的本地机器代码。缺点是你总是可以对汇编代码进行远远超出Graal所能做的任何事情的微调，不管它在未来有多大的发展。

然而，在现实世界中，事情看起来有点不同。优化代码——特别是汇编代码——需要开发人员付出大量努力。编写一个人人都能理解、维护和优化的解释器，并通过Truffle和GraalVM将其编译成汇编代码，效率更高。两者都是用Java编写的，所以很多人也有可能对这些项目进行优化。

GraalVM项目负责人Thomas Würthinger在2019年12月的一次采访中报告称，该团队目前正在设立一个由公司代表组成的咨询委员会。一方面，这听起来像是一个官僚过程，使得单个开发人员很难提供请求。另一方面，这表明大公司有兴趣改进GraalVM。也许这是一个好兆头，支持我们的希望，GraalVM为我们准备了更多。

编写自己的编程语言！

在学术界，Graal的成功可能还有另一个驱动力。Truffle使您能够编写一种新的编程语言。我们很好奇这会导致什么。

在过去的十年中，我们已经看到了大量探索新概念的新语言。如果你在这个行业工作，你可能已经错过了这一点，因为Java、JavaScript和C/C++占主导地位。但主流语言中引入的许多新概念都在次要语言中进行了尝试。

例如，Groovy和Ruby使动态类型化出名。随着Scala和Groovy的出现，流和函数编程成为现实。后来，Kotlin和Ceylon在最终进入Java8之前接受了这个想法。编译时空安全性在Kotlin和Ceylon的帮助下进入了Java世界。Scala演示了如何在没有痛苦的情况下使用不变性模式。这反过来又使Akka能够释放反应式编程和多核CPU的能力。

作为创新实验室的学术和实验编程语言

我们对早期关于枚举、值类型和自动装箱的讨论了解不多。不过，到目前为止，你已经看到了一种模式：在将游戏规则改变者引入数百万开发人员使用的语言之前，最好用一种鲜为人知的语言来处理这个想法。如果开发人员知道他们正在进行最前沿的工作，他们会更宽容地破坏更改。能够为新语言贡献自己的想法和投入，他们感到荣幸。

主流语言是完全不同的一块蛋糕。例如，尝试在Java中消除类型擦除。我们敢说，那是不可能的。你知道，类型擦除是一个伟大的想法-它确实是伟大的这在当时解决了很多问题。问题是它消除了语言设计者的许多头痛问题。发布该功能后，结果在野外引发了问题。大多数开发人员甚至不会注意到，但是类型擦除对于框架设计者来说是痛苦的。最好用一种小型语言来尝试这个想法，将Gson或Jackson之类的东西移植到它上面，并了解类型擦除的缺点。就我们所见，这正是Java语言设计师现在所做的。

使用Truffle实现语言的简单性使得使用新概念变得更加容易。Truffle将编写一种像样的语言所需的时间缩短了一半。此外，Truffle成功实现了Futumara项目，大大提高了您的宠物语言的性能。这反过来也是说服开发人员选择您的语言的关键。

云计算，主要驱动力

然而，我们仍然没有提到最大的关键驱动因素。GraalVM的独特卖点是它的AOT编译器。二十多年后，我们终于可以将Java编译成本地机器代码。更重要的是，现在我们有了一个需要本机代码的用例。最重要的是Amazon Lambda函数（以及其他云提供商提供的同级函数）。

Lambda函数的令人兴奋之处在于，您只需按次付费。只有在代码运行时才需要付费。如果没有人打电话给你，你就不用付钱。为了使这成为云提供商引人注目的商业案例，他们必须在无人使用时关闭您的虚拟机。这反过来意味着您的客户经常遭受冷启动延迟。根据我们看到的许多幻灯片和会议谈话，对于一个简单的Spring Boot服务来说，这相当于三秒钟，给或拿几个。在一个被搜索引擎主宰的世界里，对迟钝网站的惩罚太多了。大型网店报告说，如果他们的网页速度减慢十分之一秒，就会对销售额产生影响。这将使您的冷启动春季开机服务处于何处？

AOT编译器解决了这个问题。传统上，Java启动缓慢，因为它必须加载数千个类。但是，您的简单CRUD应用程序只使用这些类中的一小部分。您不需要使用Spring Boot的全部功能来响应GET请求。正如Helidon、Micronaut或Express.js（在Node.js世界中）等框架所显示的那样，三行代码也能很好地完成这一任务。

AOT编译器将您的代码分解为必要的代码，并发出预编译的机器代码。如果幸运的话，这只是三行Helidon代码，加上支持这三行代码所需的基础设施。但除此之外什么都没有。

更好的是，该代码可以随时使用，而不需要任何昂贵的基础设施来加载和初始化。根据我们看到的一些营销幻灯片，将Quarkus或Helidon之类的云原生框架添加到等式中，最终得到的Lambda函数响应时间为0.005秒。我们将在本系列的最后部分对此进行测试。敬请期待！

意想不到的事

在过去的一年中，一些开发者开始接受GraalVM。例如，米切尔·博尔肯特创造了巴巴什卡。这是一个Clojure解释器，由GraalVM编译为本地映像。它与Linux或macOS shell无缝集成，允许您用Clojure代码替换bash命令。从该项目的受欢迎程度来看——大约14个月内就有1500名GitHub明星参与其中——它达到了最佳状态。

能够编译为本机可执行文件似乎也是JavaFX社区的一件事。您不必安装Java，也不必安装JavaFX来运行本机编译的JavaFX应用程序。这就省去了在你公司数千台PC上安装这样一个应用程序的麻烦。

GraalVM似乎也推动了微服务框架的全新浪潮。例如，有Quarkus。简而言之，Quarkus是一个行业标准框架的集合，以及支持这些框架生成本机二进制文件的扩展。

我们将在本系列中研究这些大胆的主张。在这一点上，我们已经可以说GraalVM是对几十年来优化JVM的斗争的一种新的尝试。它释放了多语言编程的力量。多语言编程比Rhino或Nashorn等老方法快几个数量级。因此，当我们抱怨性能时，我们有点不公平：我们将JavaScript性能与V8引擎进行比较，而不是与Nashorn进行比较。令我们失望的是，使用GraalVM的多语言编程仍然使用相同的基于字符串的方法，因此我们怀疑使用多种语言编写程序是否有趣。也许我们将来会看到。

尽管如此，我们预计GraalVM将在云本地计算领域以及R、Python和Ruby等编程语言领域产生重大影响。我们还对在Java或JavaScript应用程序中集成低级C/C++代码感到兴奋。GraalVM是一个从过去与Java世界隔绝的许多开发人员社区的经验中获益的机会。

原文地址：https://www.beyondjava.net/what-about-graalvm