`
RednaxelaFX
  • 浏览: 3047975 次
  • 性别: Icon_minigender_1
  • 来自: 海外
社区版块
存档分类
最新评论

HotSpot的JIT编译器遇到简单无限循环时

WindowsUbuntuXPJDKSUN 
阅读更多
对下面这种带有简单无限循环的Java程序， 
// java -XX:+PrintCompilation -XX:+PrintAssembly TestC2InfiniteLoop

public class TestC2InfiniteLoop {
    public static void foo() {
        while (true) { int i = 1; }
    }
    
    public static void main(String[] args) {
        foo();
    }
}


HotSpot的JIT编译器会：

1、client模式：执行命令： 
java -XX:+PrintCompilation -XX:+PrintAssembly TestC2InfiniteLoop

C1会编译代码，会将循环内无用的代码都消除掉，但不会把循环本身消除： 
  1%      TestC2InfiniteLoop::foo @ 0 (5 bytes)
Decoding compiled method 0x00bc6748:
Code:
[Disassembling for mach='i386']
[Entry Point]
[Verified Entry Point]
  ;;  block B2 [0, 0]

  0x00bc6810: mov    %eax,-0x4000(%esp)
  0x00bc6817: push   %ebp
  0x00bc6818: mov    %esp,%ebp
  0x00bc681a: sub    $0x18,%esp         ;*iconst_1
                                        ; - TestC2InfiniteLoop::foo@0 (line 5)
  ;;  block B3 [0, 0]

  0x00bc681d: nop    
  0x00bc681e: nop    
  0x00bc681f: nop                       ; OopMap{off=16}
                                        ;*goto
                                        ; - TestC2InfiniteLoop::foo@2 (line 5)
  ;;  block B0 [0, 2]

  0x00bc6820: test   %eax,0x970100      ;   {poll}
  ;;   26 branch [AL] [B0] 
  0x00bc6826: jmp    0x00bc6820         ;*goto
                                        ; - TestC2InfiniteLoop::foo@2 (line 5)
  ;;  block B1 [0, 0]

  0x00bc6828: mov    %eax,-0x4000(%esp)
  0x00bc682f: push   %ebp
  0x00bc6830: mov    %esp,%ebp
  0x00bc6832: sub    $0x18,%esp
  0x00bc6835: mov    %ecx,(%esp)
  0x00bc6838: call   0x082ea120         ;   {runtime_call}
  ;;   20 branch [AL] [B0] 
  0x00bc683d: jmp    0x00bc6820
  0x00bc683f: nop    
  0x00bc6840: nop    
  0x00bc6841: hlt    
  0x00bc6842: hlt    
  0x00bc6843: hlt    
  0x00bc6844: hlt    
  0x00bc6845: hlt    
  0x00bc6846: hlt    
  0x00bc6847: hlt    
  0x00bc6848: hlt    
  0x00bc6849: hlt    
  0x00bc684a: hlt    
  0x00bc684b: hlt    
  0x00bc684c: hlt    
  0x00bc684d: hlt    
  0x00bc684e: hlt    
  0x00bc684f: hlt    
[Exception Handler]
[Stub Code]
  0x00bc6850: mov    $0xdead,%ebx       ;   {no_reloc}
  0x00bc6855: mov    $0xdead,%ecx
  0x00bc685a: mov    $0xdead,%edx
  0x00bc685f: mov    $0xdead,%esi
  0x00bc6864: mov    $0xdead,%edi
  0x00bc6869: jmp    0x00bc1d60         ;   {runtime_call}
  0x00bc686e: push   $0xbc686e          ;   {section_word}
  0x00bc6873: jmp    0x00b7ba40         ;   {runtime_call}

上面位于0x00bc6820和0x00bc6826的两条指令就是无限循环的残余物： 
  0x00bc6820: test   %eax,0x970100      ;   {poll}
  ;;   26 branch [AL] [B0] 
  0x00bc6826: jmp    0x00bc6820         ;*goto
                                        ; - TestC2InfiniteLoop::foo@2 (line 5)

原本在循环内的代码（int i = 1;）已经消失了，剩下的是在回边处对safepoint的轮询（test），以及循环末尾的无条件跳转（jmp）。
从编译记录看，int i = 1;对应的代码是在寄存器分配过程中被削除的。

2、server模式：执行命令： 
java -server -XX:+PrintCompilation -XX:+PrintAssembly TestC2InfiniteLoop

C2会拒绝编译这种代码，并打出日志： 
1%      TestC2InfiniteLoop::foo @ 0 (5 bytes)
1   COMPILE SKIPPED: trivial infinite loop (not retryable)

然后foo()中的无限循环就一直在解释器中执行下去了。

在hotspot/src/share/vm/opto/compile.cpp中，bool Compile::final_graph_reshaping()的代码前面有这样的注释： 
// (4) Detect infinite loops; blobs of code reachable from above but not
//     below.  Several of the Code_Gen algorithms fail on such code shapes,
//     so we simply bail out.  Happens a lot in ZKM.jar, but also happens
//     from time to time in other codes (such as -Xcomp finalizer loops, etc).
//     Detection is by looking for IfNodes where only 1 projection is
//     reachable from below or CatchNodes missing some targets.
// ...

bool Compile::final_graph_reshaping() {
  // an infinite loop may have been eliminated by the optimizer,
  // in which case the graph will be empty.
  if (root()->req() == 1) {
    record_method_not_compilable("trivial infinite loop");
    return true;
  }
  // ...
}


======================================================================

上面的实验中，如果把foo中的无限循环在源码上就变为空循环的话： 
public static void foo() {
    while (true) ;
}

则无论是在client还是server模式都不会触发对该方法的JIT编译，一直在解释器中去执行那个循环。
查看javac编译生成的字节码，可以确认该循环在字节码中是存在的： 
public static void foo();
  Signature: ()V
  Code:
   Stack=0, Locals=0, Args_size=0
   0:   goto    0
  LineNumberTable:
   line 5: 0

  StackMapTable: number_of_entries = 1
   frame_type = 0 /* same */

foo()方法中唯一的一条字节码指令就是goto 0了。有趣的是因为foo()带有无限循环，所以编译出来的字节码里连return都没有。

HotSpot解释器触发JIT编译，是通过两个计数器来进行的：方法调用计数器与回边计数器，当这两个计数器的和超过了方法调用或循环次数的预设阈值就触发对某个方法的JIT编译；这两个计数器在每个方法里都有自己的一份。其中，方法调用计数器自然是用来记录某个方法被调用的次数的，而回变计数器则用于记录某方法中所有循环执行的次数（以方法而不是单个循环为粒度）。一个空的无限循环在字节码中的表现是一条goto字节码指令，参数是字节码的相对偏移量，并且该偏移量为0（意味着它指向该goto指令自身）。解释器中有这样的代码： 
  0x0097e781: test   %edx,%edx
  0x0097e783: jns    0x0097e7a7

此时EDX持有相对偏移量，下面的JNS指令会在EDX为非负值的时候执行跳转——正好跳过了计数器自增的代码；这样就只有真正“向后跳”的goto才会使回边计数器自增。也就是说空的无限循环不会引起回边计数器的累加，默认配置下也就不会触发HotSpot进行JIT编译。

======================================================================

* 本文的测试环境是32位Windows XP SP3，E8400，Sun JDK 1.6.0 update 18
分享到：
| 简单替换URL中查询字符串的参数值的代码
评论
7 楼 RednaxelaFX 2014-12-18  
RednaxelaFX 写道
cskarry 写道
今天遇到一个问题不得其解，借这个帖子咨询下撒加：
一、目标方法
public void run0() {
                        while (!ready) {
                                number++;
                                System.out.println("OK");
                        }
                        System.out.println(ready);
                }

...

您用了-Xcomp，而且多半在第一次调用Thread1.run0()之前PrintStream类还没有加载。所以第一次编译得到的就是在while循环内和循环后各有一个uncommon_trap()的调用。于是就没有循环了，无论循环与否都跳回解释器去跑。跑到足够热了就触发了第二次编译。

您可以试试在main()里先调用一次System.out.println("get ready");之类的，确保在跑Thread1.run0()之前已经加载PrintStream类，然后再看看结果。

顺带一提，请参考我的另外一篇blog：http://rednaxelafx.iteye.com/blog/1038324
6 楼 RednaxelaFX 2014-12-18  
cskarry 写道
今天遇到一个问题不得其解，借这个帖子咨询下撒加：
一、目标方法
public void run0() {
                        while (!ready) {
                                number++;
                                System.out.println("OK");
                        }
                        System.out.println(ready);
                }

...

您用了-Xcomp，而且多半在第一次调用Thread1.run0()之前PrintStream类还没有加载。所以第一次编译得到的就是在while循环内和循环后各有一个uncommon_trap()的调用。于是就没有循环了，无论循环与否都跳回解释器去跑。跑到足够热了就触发了第二次编译。

您可以试试在main()里先调用一次System.out.println("get ready");之类的，确保在跑Thread1.run0()之前已经加载PrintStream类，然后再看看结果。
5 楼 cskarry 2014-12-17  
今天遇到一个问题不得其解，借这个帖子咨询下撒加：
一、目标方法
public void run0() {
                        while (!ready) {
                                number++;
                                System.out.println("OK");
                        }
                        System.out.println(ready);
                }

二、环境
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -Xcomp -XX:CompileCommand=dontinline,*Thread1.run0 -XX:CompileCommand=compileonly,*Thread1.run0 Thread1 > T1.log


java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)


三、结果
Line19:
[Verified Entry Point]
  0x00000001104c1220: mov    %eax,-0x14000(%rsp)
  0x00000001104c1227: push   %rbp
  0x00000001104c1228: sub    $0x10,%rsp         ;*synchronization entry
                                                ; - Thread1::run0@-1 (line 8)
  0x00000001104c122c: movzbl 0x10(%rsi),%r10d
  0x00000001104c1231: test   %r10d,%r10d
  0x00000001104c1234: je     0x00000001104c1249  ;*ifne
                                                ; - Thread1::run0@4 (line 8)
  0x00000001104c1236: mov    %rsi,%rbp
  0x00000001104c1239: mov    $0x1e,%esi
  0x00000001104c123e: nop
  0x00000001104c123f: callq  0x0000000110497f20  ; OopMap{rbp=Oop off=68}
                                                ;*getstatic out
                                                ; - Thread1::run0@28 (line 12)
                                                ;   {runtime_call}
  0x00000001104c1244: callq  0x000000010fe1bb72  ;*getstatic out
                                                ; - Thread1::run0@28 (line 12)
                                                ;   {runtime_call}
  0x00000001104c1249: incl   0xc(%rsi)          ;*synchronization entry
                                                ; - Thread1::run0@-1 (line 8)
  0x00000001104c124c: mov    %rsi,%rbp
  0x00000001104c124f: mov    $0x1e,%esi
  0x00000001104c1254: data32 xchg %ax,%ax
  0x00000001104c1257: callq  0x0000000110497f20  ; OopMap{rbp=Oop off=92}
                                                ;*getstatic out
                                                ; - Thread1::run0@17 (line 10)
                                                ;   {runtime_call}
  0x00000001104c125c: callq  0x000000010fe1bb72  ;*getstatic out
                                                ; - Thread1::run0@17 (line 10)
                                                ;   {runtime_call}



Line11356:
Decoding compiled method 0x00000001104bf3d0:
Code:
[Entry Point]
[Verified Entry Point]
[Constants]
  # {method} 'run0' '()V' in 'Thread1'
  0x00000001104bf540: callq  0x000000010fe1bb72  ;   {runtime_call}
  0x00000001104bf545: data32 data32 nopw 0x0(%rax,%rax,1)
  0x00000001104bf550: mov    %eax,-0x14000(%rsp)
  0x00000001104bf557: push   %rbp
  0x00000001104bf558: sub    $0x10,%rsp
  0x00000001104bf55c: mov    (%rsi),%rbp
  0x00000001104bf55f: mov    %rsi,%rdi
  0x00000001104bf562: movabs $0x10fe75a70,%r10
  0x00000001104bf56c: callq  *%r10
  0x00000001104bf56f: mov    0x8(%rbp),%r11d    ; implicit exception: dispatches to 0x00000001104bf601
  0x00000001104bf573: cmp    $0xef610642,%r11d  ;   {oop('Thread1')}
  0x00000001104bf57a: jne    0x00000001104bf5dc
  0x00000001104bf57c: jmp    0x00000001104bf594
  0x00000001104bf57e: xchg   %ax,%ax            ;*aload_0
                                                ; - Thread1::run0@0 (line 8)
  0x00000001104bf580: lea    (%r12,%r10,8),%rsi  ;*getstatic out
                                                ; - Thread1::run0@17 (line 10)
  0x00000001104bf584: movabs $0x7d5654668,%rdx  ;   {oop("OK")}
  0x00000001104bf58e: nop
..................


四、问题
1、看Hotspot log 感觉该方法被执行1200+次会被二次编译了，不知道是什么原因？
2、第一次编译后的代码竟然没有jmp，看不出循环怎么实现的？
4 楼 RednaxelaFX 2010-04-16  
yznxing 写道
额，，你这该不会是我上次问了下，while true
之后的研究吧！~~~

看不懂。。。
悲剧了~~~

嗯，是上次你问了之后我看了下……不过也没啥用就是了。反正结论就是HotSpot不会消掉简单无限循环。
3 楼 yznxing 2010-04-16  
额，，你这该不会是我上次问了下，while true
之后的研究吧！~~~

看不懂。。。
悲剧了~~~
2 楼 RednaxelaFX 2010-04-15  
lvgang 写道
好文，很有深度，就是看不太懂，呵呵。有个问题向博主请教，从上面打印出来的汇编代码来看，貌似是 gnu as，windows 上也能用 gnu as？

是的，这个是由GNU binutils里的as提供反汇编功能。
Sun HotSpot需要一个反汇编插件才可以使用-XX:+PrintAssembly参数来打印JIT编译生成的代码。该插件有一组通用接口，本来是可以用任意反汇编器套个适配器就行。官方提供了一个现成的版本（hsdis）是基于gas的，我懒于是就直接用它了。在Windows上直接build我还没成功过，用MinGW和Cygwin都试过不行。我用的版本是在Ubuntu上cross-compile出来的，根据插件作者提供的cross-compile指引来做没有遇到问题。
编译出来的hsdis-i386.dll放到JDK安装目录中jre/bin/server和jre/bin/client中即可。
1 楼 lvgang 2010-04-15  
好文，很有深度，就是看不太懂，呵呵。有个问题向博主请教，从上面打印出来的汇编代码来看，貌似是 gnu as，windows 上也能用 gnu as？
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

    Java JIT编译器概览.pdf

    在Java虚拟机（JVM）中，字节码通过解释器逐行执行，但当某个方法或代码块被频繁执行时，JIT编译器会介入，将其编译成本地机器码，以实现更快的执行速度。 JIT编译器的工作原理可以分为几个阶段： 1. **热点检测**...

    慢慢的回味.Hotspot JIT编译(C1)1

    HIR是HotSpot JIT编译器内部使用的高级中间代码表示形式。在编译过程中，字节码首先被转换成HIR。这一阶段的主要目的是对字节码进行分析，并将其转换为更高层次的抽象形式，便于后续优化。HIR包含了大量的类型信息和...

    java编译器1

    3. **JIT（Just-In-Time Compiler）**：JIT编译器是在运行时将JVM指令转化为本地机器代码的技术，通常包含在HotSpot JVM中。HotSpot有两个JIT编译器，C1和C2。C1（Client Compiler）主要用于快速启动，进行轻量级...

    openjdk hotspot源码

    3. **即时编译器（JIT）**：Hotspot的一大特色是它的JIT编译器，分为Client Compiler（C1）和Server Compiler（C2）。C1适用于快速启动，而C2则专注于长期运行的性能优化。JIT编译器会识别并编译经常执行的“热点”...

    hotspot 源码（JDK8）

    JIT编译器将字节码转化为机器码，以提高执行速度，同时具备逃逸分析、循环展开等优化手段。 2. **垃圾收集（Garbage Collection, GC）** Hotspot的GC策略包括Serial、Parallel、Concurrent Mark Sweep (CMS) 和G1...

    JIT.rar_Java书籍_Java_

    JIT编译器是Java虚拟机（JVM）的一部分，它的主要任务是在程序运行时将字节码转换为机器码。与传统的静态编译器不同，JIT编译器的工作方式是在运行过程中动态地进行编译，这使得它能够根据实际运行环境和数据分布...

    hllvm.JIT编译以及执行native code的流程1

    HotSpot JVM有两个主要的JIT编译器：Client Compiler (C1) 和 Server Compiler (C2)。 - C1 编译器通常用于轻量级客户端应用，它快速生成本地代码，但优化程度较低。 - C2 编译器则用于服务器端应用，它会进行更...

    JVM中[执行引擎]的所有内容-pdf

    解释器能够快速启动程序，而JIT编译器则负责在运行时将频繁执行的热点代码编译为本地机器码，以提高性能。HotSpot中的C1和C2编译器分别代表轻量级和重量级的JIT编译器，它们对代码进行不同程度的优化。 JIT编译器的...

    hotspot源码

    6. 编译优化：HotSpot的服务器模式（Server Mode）下，JIT编译器会进行多种优化，如逃逸分析、标量替换、循环展开等。这些优化技术的源码实现，是理解Java性能提升的关键。 深入研究HotSpot源码，不仅可以提高我们...

    java小型basic编译器

    6. **性能优化**：虽然Java编译器通常将代码转换为字节码，但现代JVM如HotSpot可以进行即时编译（JIT），将热点代码编译为机器码以提高运行时性能。Java小型Basic编译器可能利用这样的特性来提升Basic程序的执行效率...

    JVM Hotspot实现源码

    首先，Hotspot JVM的核心设计理念是“热Spot”优化，即通过动态分析代码执行情况，识别出经常执行的“热点”代码，然后对其进行JIT（Just-In-Time）编译，生成高效的本地机器码。这种优化策略显著提升了Java应用的...

    给HotSpot client compiler的Phi加上exact_type()

    在Java虚拟机（JVM）中，HotSpot是Oracle公司的一款高性能JVM实现，它包含两个主要的Just-In-Time（JIT）编译器：C1（也称为Client Compiler）和C2（也称为Server Compiler）。这篇博客文章《给HotSpot client ...

    动态编译与性能测量1

    为解决这一问题，JIT编译器应运而生，它在代码运行过程中，当确定某段代码将要频繁执行时，将其编译为机器码。这种惰性编译策略减少了启动时的编译时间，提升了运行时性能。 JIT编译器并非一次性编译所有代码，而是...

    Java Program in Action

    HotSpot VM中的JIT编译器是其性能优化的关键，它能够动态地选择热点代码进行优化，并将其转换为高效的机器代码。JIT编译器的主要任务包括： - **代码选择**：选择需要编译的代码片段。 - **代码优化**：进行循环展开...

    jvm技术精华-架构师必备

    Oracle公司计划在未来版本的JDK中整合这两种虚拟机的优势特性，例如使用JRockit的垃圾回收机制和Mission Control服务，同时保留HotSpot的JIT编译器和混合运行时系统。 #### 二、Java内存结构 Java内存模型主要包括...

    Java高级面试JVM虚拟机、内存结构、垃圾回收机制

    解释器负责快速启动和轻量级执行，而JIT编译器会监控运行时数据，识别出经常执行的"热点"代码并进行编译，以达到更高效的执行速度。HotSpot VM还包括了两种类型的JIT编译：标准编译用于长时间运行的方法，而OSR编译...

    mac下使用JITWatch查看JDK1.8汇编代码

    例如，可以看到循环优化、内联策略、标量替换等JIT编译器的特性。 总之，掌握在Mac上使用JITWatch查看JDK 1.8的汇编代码是一项实用的技能，它可以帮助我们更好地理解Java应用程序的内部工作原理，进行性能调优，...

    HotspotInAction.第250页 7.3 即时编译器 7.3.1 概述1

    在Java的HotSpot虚拟机中，即时编译器（JIT，Just-In-Time Compiler）扮演着关键角色，它负责将字节码转换为机器码以提高程序的运行效率。HotSpot包含两种即时编译器：客户端编译器（C1）和服务器端编译器（C2）。C1...

    hsdis-amd64.dll 资源下载

    尤其是在分析JIT编译器如何优化代码时，hsdis-amd64.dll提供了宝贵的洞察力。 使用hsdis-amd64.dll通常涉及到以下几个步骤： 1. **配置环境**：首先，你需要确保你的Java环境已经正确设置，包括JDK的安装和环境...

    java知识整理1

    4. **JIT编译器**： - **Javac**是前端编译器，将源代码编译为字节码。 - **JIT**是HotSpot虚拟机的后端编译器，运行时将字节码编译为机器码，提高执行效率。分为Client端和Server端，以适应不同场景的需求。 ...

Magicbox
Global site tag (gtag.js) - Google Analytics