写点什么

Azul ReadyNow! 力图去掉 JVM 预热

  • 2014 年 3 月 19 日
  • 本文字数:2193 字

    阅读完需:约 7 分钟

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如果代码正在改变,优化又是如何进行的呢?

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

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

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

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

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

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

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

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

Tene嗯,还有一个有趣的地方。当人们让我们提供终极解决方案时,我的第一个问题是,为什么想要这样的方案呢?通常的回答是,他们每晚重启系统,而不想预热。所以我问他们:“你们的算法两周都不会变,为什么不让代码一直跑着呢?”他们回答:“因为 GC 延迟!”

和我们合作,我们的无停顿 GC 没有那个问题。我们正在对人们进行再培训,让他们不要再重启系统。所以现在的情况是,他们需要重启的话才重启,而不是因为某些运行原因。

查看英文原文: Azul ReadyNow! Seeks to Eliminate JVM Warm-up

2014 年 3 月 19 日 06:111419
用户头像
臧秀涛 略懂技术的运营同学。

发布了 300 篇内容, 共 120.0 次阅读, 收获喜欢 30 次。

关注

评论

发布
暂无评论
发现更多内容

玩转SpringBoot2.x之缓存对象

zhuoqianmingyue

redis springboot

配置国内的pip源以提高使用pip安装python软件包的速度

良少

Python pip

程序员的修行之路-关于编程语言

牧马人

程序员

2020年3月北京BGP机房网络质量评测报告

博睿数据

运维 APM 机房 数据中心 拨测

zookeeper到nacos的迁移实践

捉虫大师

架构 nacos

使用Spring Boot和Docker构建微服务架构(一)

MaxHu

Docker 架构 容器 微服务 Spring Boot

微软:正式发布针对 .NET Core的 Winform 设计器

Geek_Willie

.net 微软 Win .net core

程序员的修行之路-关于编程语言

牧马人

程序员

使用Spring Boot和Docker构建微服务架构(二)

MaxHu

Docker 架构 容器 微服务 Spring Boot

使用Spring Boot和Docker构建微服务架构(四)

MaxHu

Docker 架构 容器 微服务 Spring Boot

游戏夜读 | 世界两大游戏评论!

game1night

Java运算符实际运用

凌轩

Java 编程语言

Spring Cloud 和 Dubbo 哪个会被淘汰?

程序猿DD

Spring Cloud dubbo

程序员的修行之路-保持良好的心态

牧马人

程序员

世界那么大,你有偏见吗?

谢锐 | Frozen

创业 技术管理

系统化服务构建-软件工程分层

图南日晟

微服务 软件工程 架构设计

美国播客节目《指数视角》专访李飞飞:疫情、 AI 伦理、人才培养

神经星星

人工智能 程序员 李飞飞 硅谷 AI 伦理

企业微信机器人在大型财务共享中心的应用实践

DT极客

数据产品经理实战-DMP搭建

第519区

产品经理 营销

Flink 完美搭档:数据存储层上的 Pravega

Apache Flink

大数据 flink 流计算 实时计算

快速入门 Nacos 作为配置中心操作

zhuoqianmingyue

nacos SpringBoot 2

短视频时代下的知识摄取

Neco.W

学习 知识管理 知识体系 短视频

linux 账户及安全管理(一 账户管理)

牧马人

Linux

我们都可能陷入经济困境

董一凡

生活

微信gif图片大小的规则

石云升

微信 GIF

是什么在背后支撑起“带货一哥”李佳琦?

博睿数据

负载均衡 APM 压测 秒杀 并发

卡巴斯基产品本地化用时能缩短 77%,怎么做到的?

葛仲君

项目管理 软件开发 本地化 开发流程

2020年3月云主机性能评测报告

博睿数据

云计算 运维 机房 数据中心 主机

后台定时统计任务太耗时如何优化一下

zhuoqianmingyue

线程池

代码刚提交暂存区,组长突然要我把新增代码 Commit另一分支怎么办?

zhuoqianmingyue

git

使用Spring Boot和Docker构建微服务架构(三)

MaxHu

Docker 架构 容器 微服务 Spring Boot

Azul ReadyNow!力图去掉JVM预热-InfoQ