Java HotSpot VM中的JIT编译

标签: 好文推荐 并发译文 client hotspot inline | 发表时间:2013-05-13 22:13 | 作者:郭蕾
出处:http://ifeve.com


原文地址 译者:郭蕾 校对:丁一

本文是Java HotSpot VM and just-in-time(JIT) compilation系列的第一篇。

Java HotSpot虚拟机是Oracle收购Sun时获得的,JVM和开源的OpenJDK都是以此虚拟机为基础发展的。如同其它虚拟机,HotSpot虚拟机为字节码提供了一个运行时环境。实际上,它主要会做这三件事情:

  • 执行方法所请求的指令和运算。
  • 定位、加载和验证新的类型(即类加载)。
  • 管理应用内存。

最后两点都是各自领域的大话题,所以这篇文章中只关注代码执行。

JIT编译

Java HotSpot是一个混合模式的虚拟机,也就是说它既可以解释字节码,又可以将代码编译为本地机器码以更快的执行。通过配置-XX:+PrintCompilation参数,你可以在log文件中看到方法被JIT编译时的信息。JIT编译发生在运行时 —— 方法经过多次运行之后。到方法需要使用到的时候,HotSpot VM会决定如何优化这些代码。

如果你好奇JIT编译带来的性能提升,可以使用-Djava.compiler=none将其关掉然后运行基准测试程序来看看它们的差别。

Java HotSpot虚拟机可以运行在两种模式下:client或者server。你可以在JVM启动时通过配置-client或者-server选项来选择其中一种。两种模式都有各自的适用场景,本文中,我们只会涉及到server模式。

两种模式最主要的区别是server模式下会进行更激进的优化 —— 这些优化是建立在一些并不永远为真的假设之上。一个简单的 保护条件(guard condition)会验证这些假设是否成立,以确保优化总是正确的。如果假设不成立,Java HotSpot虚拟机将会撤销所做的优化并退回到解释模式。也就是说Java HotSpot虚拟机总是会先检查优化是否仍然有效,不会因为假设不再成立而表现出错误的行为。

在server模式下,Java HotSpot虚拟机会默认在解释模式下运行方法10000次才会触发JIT编译。可以通过虚拟机参数-XX:CompileThreshold来调整这个值。比如-XX:CompileThreshold=5000会让触发JIT编译的方法运行次数减少一半。( 译者注:有关JIT触发条件可参考《深入理解Java虚拟机》第十一章以及《Java Performance》第三章HotSpot VM JIT Compilers小节)

这可能会诱使新手将编译阈值调整到一个非常低的值。但要抵挡住这个诱惑,因为这样可能会降低虚拟机性能,优化后减少的方法执行时间还不足以抵消花在JIT编译上的时间。

当Java HotSpot虚拟机能为JIT编译收集到足够多的统计信息时,性能会最好。当你降低编译阈值时,Java HotSpot虚拟机可能会在非热点代码的编译中花费较多时间。有些优化只有在收集到足够多的统计信息时才会进行,所以降低编译阈值可能导致优化效果不佳。

另外一方面,很多开发者想让一些重要方法在编译模式下尽快获得更好的性能。

解决此问题一般是在进程启动后,对代码进行预热以使它们被强制编译。对于像订单系统或者交易系统来说,重要的是要确保预热不会产生真实的订单。

Java HotSpot虚拟机提供了很多参数来输出JIT的编译信息。最常用的就是前文提到的PrintCompilation,也还有一些其它参数。

接下来我们将使用PrintCompilation来观察Java HotSpot虚拟机在运行时编译方法的成效。但先有必要说一下用于计时的System.nanoTime()方法。

计时方法

Java为我们提供了两个主要的获取时间值的方法:currentTimeMillis()和nanoTime().前者对应于我们在实体世界中看到的时间(所谓的钟表时间),它的分辨率能满足大多数情况,但不适用于低延迟的应用。

纳秒计时器拥有更高的分辨率。这种计时器度量时间的间隔极短。1纳秒是光在光纤中移动20CM所需的时间,相比之下,光通过光纤从伦敦传送到纽约大约需要27.5毫秒。

正因为纳秒级别的时间戳的分辨率如此之高,注定了其不够精确,使用时需要注意。

如,currentTimeMillis()能很好的在机器间同步,可以用于测量网络延迟,但nanoTime()不能跨机器使用。

接下来将上面的理论付诸实践,来看一个很简单(但极其强大)的JIT编译技术。

方法内联

方法内联是编译器优化的关键手段之一。方法内联就是把方法的代码“复制”到发起调用的方法里,以消除方法调用。这个功能相当重要,因为调用一个小方法可能比执行该小方法的方法体耗时还多。

JIT编译器可以进行渐进内联,开始时内联简单的方法,如果可以进行其它优化时,就接着优化内联后的较大的代码块。

Listing1,Listing1A以及Listing1B是个简单的测试,将直接操作字段和通过getter/setter方法做了对比。如果简单的getters和setters方法没有使用内联的话,那调用它们的代价是相当大的,因为方法调用比直接操作字段代价更高。

Listing1:

public class Main {
    private static double timeTestRun(String desc, int runs, 
		Callable<Double> callable) throws Exception {
        long start = System.nanoTime();
        callable.call();
        long time = System.nanoTime() - start;
        return (double) time / runs;
    }

    // Housekeeping method to provide nice uptime values for us
    private static long uptime() {
        return ManagementFactory.getRuntimeMXBean().getUptime() + 15; 
    // fudge factor
    }

    public static void main(String... args) throws Exception {
        int iterations = 0;
        for (int i : new int[]
			{ 100, 1000, 5000, 9000, 10000, 11000, 13000, 20000, 100000} ) {
            final int runs = i - iterations;
            iterations += runs;

            // NOTE: We return double (sum of values) from our test cases to
            // prevent aggressive JIT compilation from eliminating the loop in
            // unrealistic ways
            Callable<Double> directCall = new DFACaller(runs);
            Callable<Double> viaGetSet = new GetSetCaller(runs);

            double time1 = timeTestRun("public fields", runs, directCall);
            double time2 = timeTestRun("getter/setter fields", runs, viaGetSet);

            System.out.printf("%7d %,7d\t\tfield access=%.1f ns, getter/setter=%.1f ns%n",
				uptime(), iterations, time1, time2);
            // added to improve readability of the output
            Thread.sleep(100);
        }
    }
}

Listing1A:

public class DFACaller implements Callable<Double>{
    private final int runs;

    public DFACaller(int runs_) {
        runs = runs_;
    }

    @Override
    public Double call() {
        DirectFieldAccess direct = new DirectFieldAccess();
        double sum = 0;
        for (int i = 0; i < runs; i++) {
            direct.one++;
            sum += direct.one;
        }
        return sum;
    }
}

public class DirectFieldAccess {
    int one;
}

Listing1B:

public class GetSetCaller implements Callable<Double> {
    private final int runs;

    public GetSetCaller(int runs_) {
        runs = runs_;
    }

    @Override
    public Double call() {
        ViaGetSet getSet = new ViaGetSet();
        double sum = 0;
        for (int i = 0; i < runs; i++) {
            getSet.setOne(getSet.getOne() + 1);
            sum += getSet.getOne();
        }
        return sum;
    }
}

public class ViaGetSet {
    private int one;

    public int getOne() {
        return one;
    }

    public void setOne(int one) {
        this.one = one;
    }
}

如果使用java -cp. -XX:PrintCompilation Main 运行测试用例,就能看到性能上的差异(见Listing2)。

Listing2

 31    1     java.lang.String::hashCode (67 bytes) 
 36   100    field access=1970.0 ns, getter/setter=1790.0 ns 
 39    2     sun.nio.cs.UTF_8$Encoder::encode (361 bytes) 
 42    3     java.lang.String::indexOf (87 bytes) 
141   1,000 field access=16.7 ns, getter/setter=67.8 ns 
245   5,000 field access=16.8 ns, getter/setter=72.8 ns 
245    4     ViaGetSet::getOne (5 bytes) 
348   9,000 field access=16.0 ns, getter/setter=65.3 ns 
450    5     ViaGetSet::setOne (6 bytes) 
450  10,000 field access=16.0 ns, getter/setter=199.0 ns 
553    6     Main$1::call (51 bytes) 
554    7     Main$2::call (51 bytes) 
556    8     java.lang.String::charAt (33 bytes) 
556  11,000 field access=1263.0 ns, getter/setter=1253.0 ns 
658  13,000 field access=5.5 ns, getter/setter=1.5 ns 
760  20,000 field access=0.7 ns, getter/setter=0.7 ns 
862 100,000 field access=0.7 ns, getter/setter=0.7 ns 

这些是什么意思?Listing2中的第一列是程序启动到语句执行时所经过的毫秒数,第二列是方法ID(编译后的方法)或遍历次数。

注意:测试中没有直接使用String和UTF_8类,但它们仍然出现在编译的输出中,这是因为平台使用了它们。

从Listing2中的第二行可以发现,直接访问字段和通过getter/setter都是比较慢的,这是因为第一次运行时包含了类加载的时间,下一行就比较快了,尽管此时还没有任何代码被编译。

另外要注意下面几点:

  • 在遍历1000和5000次时,直接操作字段比使用getter/setter方法快,因为getter 和setter还没有内联或优化。即便如此,它们都还相当地快。
  • 在遍历9000次时,getter方法被优化了(因为每次循环中调用了两次),使性能有小许提高。
  • 在遍历10000次时,setter方法也被优化了,因为需要额外花费时间去优化,所以执行速度降下来了。
  • 最终,两个测试类都被优化了:
    • DFACaller直接操作字段,GetSetCaller使用getter和setter方法。此时它们不仅刚被优化,还被内联了。
    • 从下一次的遍历中可以看到,测试用例的执行时间仍不是最快的。
  • 在13000次遍历之后,两种字段访问方式的性能都和最后更长时间测试的结果一样好,我们已经达到了性能的稳定状态。

需要特别注意的是,直接访问字段和通过getter/setter访问在稳定状态下的性能是基本一致的,因为方法已经被内联到GetSetCaller中,也就是说在viaGetSet中所做的事情和directCall中完全一样。

JIT编译是在后台进行的。每次可用的优化手段可能随机器的不同而不同,甚至,同个程序的多次运行期间也可能不一样。

总结

这篇文章中,我所描述的只是JIT编译的冰山一角,尤其是没有提到如何写出好的基准测试以及如何使用统计信息以确保不会被平台的动态性所愚弄。

这里使用的基准测试非常简单,不适合做为真实的基准测试。在第二部分,我计划向您展示一个真实的基准测试并继续深入JIT编译的过程。

您可能感兴趣的文章

相关 [java hotspot vm] 推荐:

Java HotSpot VM中的JIT编译

- - 并发编程网 - ifeve.com
原文地址 译者:郭蕾 校对:丁一. 本文是Java HotSpot VM and just-in-time(JIT) compilation系列的第一篇. Java HotSpot虚拟机是Oracle收购Sun时获得的,JVM和开源的OpenJDK都是以此虚拟机为基础发展的. 如同其它虚拟机,HotSpot虚拟机为字节码提供了一个运行时环境.

java 1.6.0_38-b05 vm 20.13-b02优化手记

- - 五四陈科学院-坚信科学,分享技术
以下内容由 [五四陈科学院]提供. rose框架(底层是spring). -Xmx5000M // max的heap的大小. -Xms5000M // min的heap的大小,就是一初始给的大小,不够先GC,还不够再加,直到max. -Xmn2000M //young区的大小,一般来讲:heap=Y+O,P是额外的值.

VM將可跨LAN移轉

- MorrisC - iThome Online
思科與VMware合作,推出跨LAN進行VMotion的新網通技術VXLAN(Virtual Extensible LAN),改變原先IEEE 802.1Q用於辨識位於不同LAN虛擬機器的封包格式,從12位元增加為24位元,可記錄更多的封包資訊,以分辨不同網段.

HotSpot JVM 触发 OutOfMemoryError 参数

- - 编程语言 - ITeye博客
正好今天是愚人节,就来说点骗子的东西吧~. 时不时的我就会听见有人抱怨说,他的HotSpot JVM不停的在垃圾回收,可是每次回收完后堆却还是满的. 当他们发现这是因为JVM的内存已经不够了之后,通常会问这么个问题,为什么JVM不抛一个OutOfMemoryError(OOME)呢. 毕竟来说,由于内存不足,我的程序都已经没法继续跑了,对吧.

[译] HotSpot JVM 内存管理

- - IT瘾-dev
HotSpot JVM 内存管理. 更新时间:2018-03-28. 关于 JVM 内存管理或者说垃圾收集,大家可能看过很多的文章了,笔者准备给大家总结下. 这算是系列的第一篇,接下来一段时间会持续更新. 本文主要是翻译《 Memory Management in the Java HotSpot Virtual Machine》白皮书的前四章内容,这是 2006 的老文章了,当年发布这篇文章的还是 Sun Microsystems,以后应该会越来越少人记得这家曾经无比伟大的公司了.

虚拟机Oracle VM VirtualBox安装windows8

- - 牛B博客 niub.us
昨天晚上微软公布了Windows 8 Release Preview下载地址:. 中文(简体)32 位 (x86)(2.48 GB) http://iso.esd.microsoft.com/WRPDL/D29D6C5B1D8AF956B5DA9DF738CFD92DFD4F6C8FB/Windows8-ReleasePreview-32bit-ChineseSimplified.iso.

HotSpot 垃圾回收算法实现

- - 码蜂笔记
《深入理解Java虚拟机:JVM高级特性与最佳实践》-笔记. 在可达性分析期间整个系统看起来就像被冻结在某个时间点上,不可以出现分析过程中对象引用关系还在不断变化的情况. 一致性要求导致GC进行时必须停顿所有Java执行线程. 即使在号称不会发生停顿的CMS收集器中,枚举根节点时也是必须停顿的. HotSpot使用的是准确式GC,当执行系统停顿下来后,并不需要一个不漏地检查完所有执行上下文和全局的引用位置,这是通过一组称为OopMap的数据结构来达到的.

VM性能的快速测试方法

- - 婉兮清扬
前段时间陆续发布了一些对公有云服务性能评测的数据. 经常有同行问我怎么样去做这些性能评测. 其实这些性能评测都很简单,任何一个具备Linux基础知识的工程师都可以完成. 我们通常使用UnixBench来评估虚拟机整机性能,mbw来评估内存性能,iozone来评估磁盘IO性能,iperf来评估网络性能,pgbench来评估数据库性能.

Hotspot Shield即将推出移动设备支持

- 建军 - iGFW
美国AnchorFree公司旗下的Hotspot Shield和ExpatShield软件都是优秀的免费VPN软件. 公司自2005年提供服务以来已经有上千万的用户通过Hotspot Shield软件突破网络审查保护网络隐私. Hotspot Shield推特上说即将推出对Iphone, Ipad and Itouch的支持,据称是有别于以前直接给服务器帐号的方式,这次是一个推出一个应用程序,有简单的VPN控制界面(估计还是带广告的Cisco IPSec VPN类型).

免费不限流量VPN代理软件Hotspot Shield

- 勇 - 软矿
每当我发表关于付费VPN的文章时,都会有人问我有没有免费的VPN. 早些时候我就介绍过免费的VPN服务“PacketiX.NET”,稍有关注软矿的朋友应该都知道. 但又有很多朋友反映PacketiX.NET不尽人意. 但天下没有免费的午餐啊,免费的VPN都会存在那样这样的问题. 或者笔者介绍的Astrill VPN,iVPN和PureVPN有点小贵,但是这些付费VPN提供的虚拟网络却相对稳定和速度有保证.