微信号:infoqchina

介绍:有内容的技术社区媒体

Azul ReadyNow!力图去掉JVM预热

2014-03-21 18:06 InfoQ

JVM制造商Azul Systems宣布发布ReadyNow!,提供了一系列为消除Java虚拟机的预热(Warm-up)而设计的特性。预热是应用所有者执行的一种惯常做法,意在给JVM足够的时间去了解将哪段代码编译为机器码,从而利用JIT编译器优化。ReadyNow!配备了Azul最新版的Zing Java运行时,即5.9版本。


该公司提到,ReadyNow!特别适合应用于金融市场,这类市场中的应用对关键时刻的峰值系统性能有要求,比如开盘时,或者遇到量贩或交易行为中无法预料的激增时。


我们先来看一点背景知识:Java平台有一个众所周知的特性,即在Java应用启动并执行时,JVM把应用编译为可执行的机器码。随着应用继续运行,JVM将评估应用的执行历史,然后编译应用代码中较为重要的部分,以提高性能。因此,应用的性能会随着时间的推移而改进。


有的应用团队从一开始就要求高性能,在他们之间有一个很常用的实践做法,即通过为应用提供模拟的“mock”数据对其进行预热。据Azul介绍,这种实践是有风险的,未必能产生预期的优化。InfoQ就ReadyNow!采访了Gil Tene,他是Azul的联合创始人与CTO。


InfoQ:没有预热的优化看上去非常矛盾。你能谈一下JIT是如何在不进行预热的情况下实现优化的吗?


Tene:我们去年用了一年的时间分析原因。我们和客户仔细检查了这一问题,并提供了一些可能的解决方案。但是当我们与客户分析这些方案时,我们知道了起作用和不起作用的分别是什么。ReadyNow!的一个技巧是进行预测性优化;而传统的JVM会优化一条路径,我们则是优化两条路径,而且是提前1%进行优化,而非在关键时间窗口之间优化。我们添加了激进的类加载(aggressive class loading)机制:发现作用域中的类时就加载它们,但不初始化,因此如果代码不走那条路,就不必先加载该类。而且我们发现,往往有很多时间花在加载类上。现在我们可以提早对类进行初始化,但是初始化顺序是有语义的,所以这需要控制,因此我们通过提供API的方式向开发者提供了控制权,这样开发者就可以为JIT编译器提供线索,指出要初始化和优化的内容。因此应用代码可以说,我想让JVM现在编译这一块,或者我们想让JVM丢弃一切,重新编译,比如初始化代码针对错误的分支进行了优化时,我们想重新优化。


在算法交易中通常会观察到一个有趣的场景,有些算法以很高的频率观察市场状况,但交易并不频繁。所以我们关心的代码很少执行。而这恰恰是需要快速运行的代码。开发者希望告诉编译器这段代码是他们所关心的,但是运行不那么频繁。这就是ReadyNow!的“编译器指令(compiler directives)”的一个例子。


所有这些我们的产品都已经提供了。未来数月我们会提供预热的“圣杯”。举个例子,比如说昨天业务很繁忙,遇到了很多事,代码都相当平稳地处理掉了。所以为什么不将昨天的优化应用于今天的运行呢?我们正在做的就是这个。这还不是最终的解决方案;它非常适合代码不会变化的特定应用。例如,匹配引擎就是一个非常合适的用例,因为它相当稳定,然而在算法交易系统中,代码天天变,这种优化就是错误的了,在这种情况下,昨天的优化可能行不通。


InfoQ:如果代码正在改变,优化又是如何进行的呢?


Tene:ReadyNow!的目的就在于此。开发者需要向系统中加入一些优化预热代码,这样就不会发生去优化(deoptimization)了,而且今天我们可以确保不发生去优化,即便是新代码。如果没有历史信息,圣杯也没什么效果。不过不管有没有历史信息,我们的激进的类加载、激进的初始化和激进的编译器API,仍然是可以工作的。


InfoQ:你提到的“去优化”是什么意思?


Tene:我们知道预热JVM很是困难,因为JIT编译器会做一些非常有趣的优化。比如,它会不断地监控正在执行的代码,并假设尚未运行的代码永远都不运行。遗憾的是,当人们预热交易系统时,只是运行一些代码,并不能体现所有的东西,所以JVM生成的代码会针对这些模拟运行产生不正确的优化。但是之后JVM发现执行模式中有些东西改变了,它就必需回退,运行一段时间的解释代码,以收集新的数据指标。这个阶段被称作去优化。


去优化还有其他一些例子。比如,从来没运行过的类现在必须被加载到正在运行的JVM中,而加载类是需要时间的。


我们听到一些恐怖的事情是,有人了解了除了真正的交易,都会导致去优化,于是他们就执行一次真正的交易,然后取消掉该交易。想想其风险吧,虽然这类交易可以通过控制使其不进入市场,但是万一出点错,可能就是上百万美元的错误。你知道,什么错误都有可能出现,这是玩火。


InfoQ:你提到该特性是应客户的要求加入的?


Tene:在Azul,我们经常发现自己置身低延迟Java系统中,这是我们遇到的第一个并非用户要求的特性。对于要求的特性,我自己有笔账,这个特性已经被要求了22次,这意味着有22个不相关的人要求我解决交易预热问题。


InfoQ:感谢接受我们的采访。最后您还有什么要说的吗?


Tene:嗯,还有一个有趣的地方。当人们让我们提供终极解决方案时,我的第一个问题是,为什么想要这样的方案呢?通常的回答是,他们每晚重启系统,而不想预热。所以我问他们:“你们的算法两周都不会变,为什么不让代码一直跑着呢?”他们回答:“因为GC延迟!”和我们合作,我们的无停顿GC没有那个问题。我们正在对人们进行再培训,让他们不要再重启系统。所以现在的情况是,他们需要重启的话才重启,而不是因为某些运行原因。


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 R中的数据结构——列表 一种基于Lucene的实时搜索方案 程序员的世界,你真的懂么 开源,一种新的平台之战 用10分钟做点事帮助今后的程序员生涯