- 浏览: 3053246 次
- 性别:
- 来自: 海外
文章分类
- 全部博客 (430)
- Programming Languages (23)
- Compiler (20)
- Virtual Machine (57)
- Garbage Collection (4)
- HotSpot VM (26)
- Mono (2)
- SSCLI Rotor (1)
- Harmony (0)
- DLR (19)
- Ruby (28)
- C# (38)
- F# (3)
- Haskell (0)
- Scheme (1)
- Regular Expression (5)
- Python (4)
- ECMAScript (2)
- JavaScript (18)
- ActionScript (7)
- Squirrel (2)
- C (6)
- C++ (10)
- D (2)
- .NET (13)
- Java (86)
- Scala (1)
- Groovy (3)
- Optimization (6)
- Data Structure and Algorithm (3)
- Books (4)
- WPF (1)
- Game Engines (7)
- 吉里吉里 (12)
- UML (1)
- Reverse Engineering (11)
- NSIS (4)
- Utilities (3)
- Design Patterns (1)
- Visual Studio (9)
- Windows 7 (3)
- x86 Assembler (1)
- Android (2)
- School Assignment / Test (6)
- Anti-virus (1)
- REST (1)
- Profiling (1)
- misc (39)
- NetOA (12)
- rant (6)
- anime (5)
- Links (12)
- CLR (7)
- GC (1)
- OpenJDK (2)
- JVM (4)
- KVM (0)
- Rhino (1)
- LINQ (2)
- JScript (0)
- Nashorn (0)
- Dalvik (1)
- DTrace (0)
- LLVM (0)
- MSIL (0)
最新评论
-
mldxs:
虽然很多还是看不懂,写的很好!
虚拟机随谈(一):解释器,树遍历解释器,基于栈与基于寄存器,大杂烩 -
HanyuKing:
Java的多维数组 -
funnyone:
Java 8的default method与method resolution -
ljs_nogard:
Xamarin workbook - .Net Core 中不 ...
LINQ的恶搞…… -
txm119161336:
allocatestlye1 顺序为 // Fields o ...
最近做的两次Java/JVM分享的概要
对下面这种带有简单无限循环的Java程序,
HotSpot的JIT编译器会:
1、client模式:执行命令:
C1会编译代码,会将循环内无用的代码都消除掉,但不会把循环本身消除:
上面位于0x00bc6820和0x00bc6826的两条指令就是无限循环的残余物:
原本在循环内的代码(int i = 1;)已经消失了,剩下的是在回边处对safepoint的轮询(test),以及循环末尾的无条件跳转(jmp)。
从编译记录看,int i = 1;对应的代码是在寄存器分配过程中被削除的。
2、server模式:执行命令:
C2会拒绝编译这种代码,并打出日志:
然后foo()中的无限循环就一直在解释器中执行下去了。
在hotspot/src/share/vm/opto/compile.cpp中,bool Compile::final_graph_reshaping()的代码前面有这样的注释:
======================================================================
上面的实验中,如果把foo中的无限循环在源码上就变为空循环的话:
则无论是在client还是server模式都不会触发对该方法的JIT编译,一直在解释器中去执行那个循环。
查看javac编译生成的字节码,可以确认该循环在字节码中是存在的:
foo()方法中唯一的一条字节码指令就是goto 0了。有趣的是因为foo()带有无限循环,所以编译出来的字节码里连return都没有。
HotSpot解释器触发JIT编译,是通过两个计数器来进行的:方法调用计数器与回边计数器,当这两个计数器的和超过了方法调用或循环次数的预设阈值就触发对某个方法的JIT编译;这两个计数器在每个方法里都有自己的一份。其中,方法调用计数器自然是用来记录某个方法被调用的次数的,而回变计数器则用于记录某方法中所有循环执行的次数(以方法而不是单个循环为粒度)。一个空的无限循环在字节码中的表现是一条goto字节码指令,参数是字节码的相对偏移量,并且该偏移量为0(意味着它指向该goto指令自身)。解释器中有这样的代码:
此时EDX持有相对偏移量,下面的JNS指令会在EDX为非负值的时候执行跳转——正好跳过了计数器自增的代码;这样就只有真正“向后跳”的goto才会使回边计数器自增。也就是说空的无限循环不会引起回边计数器的累加,默认配置下也就不会触发HotSpot进行JIT编译。
======================================================================
* 本文的测试环境是32位Windows XP SP3,E8400,Sun JDK 1.6.0 update 18
您用了-Xcomp,而且多半在第一次调用Thread1.run0()之前PrintStream类还没有加载。所以第一次编译得到的就是在while循环内和循环后各有一个uncommon_trap()的调用。于是就没有循环了,无论循环与否都跳回解释器去跑。跑到足够热了就触发了第二次编译。
您可以试试在main()里先调用一次System.out.println("get ready");之类的,确保在跑Thread1.run0()之前已经加载PrintStream类,然后再看看结果。
顺带一提,请参考我的另外一篇blog:http://rednaxelafx.iteye.com/blog/1038324
您用了-Xcomp,而且多半在第一次调用Thread1.run0()之前PrintStream类还没有加载。所以第一次编译得到的就是在while循环内和循环后各有一个uncommon_trap()的调用。于是就没有循环了,无论循环与否都跳回解释器去跑。跑到足够热了就触发了第二次编译。
您可以试试在main()里先调用一次System.out.println("get ready");之类的,确保在跑Thread1.run0()之前已经加载PrintStream类,然后再看看结果。
嗯,是上次你问了之后我看了下……不过也没啥用就是了。反正结论就是HotSpot不会消掉简单无限循环。
是的,这个是由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中即可。
// 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
评论
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
今天遇到一个问题不得其解,借这个帖子咨询下撒加:
一、目标方法
二、环境
三、结果
Line19:
Line11356:
四、问题
1、看Hotspot log 感觉该方法被执行1200+次会被二次编译了,不知道是什么原因?
2、第一次编译后的代码竟然没有jmp,看不出循环怎么实现的?
一、目标方法
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?
发表评论
-
The Prehistory of Java, HotSpot and Train
2014-06-02 08:18 0http://cs.gmu.edu/cne/itcore/vi ... -
MSJVM and Sun 1.0.x/1.1.x
2014-05-20 18:50 0当年的survey paper: http://www.sym ... -
Sun JDK1.4.2_28有TieredCompilation
2014-05-12 08:48 0原来以前Sun的JDK 1.4.2 update 28就已经有 ... -
IBM JVM notes (2014 ver)
2014-05-11 07:16 0Sovereign JIT http://publib.bou ... -
class data sharing by Apple
2014-03-28 05:17 0class data sharing is implement ... -
HotSpot Server VM与Server Class Machine
2014-02-18 13:21 0HotSpot VM历来有Client VM与Server V ... -
Java 8的lambda表达式在OpenJDK8中的实现
2014-02-04 12:08 0三月份JDK8就要发布首发了,现在JDK8 release c ... -
GC stack map与deopt stack map的异同
2014-01-08 09:56 0两者之间不并存在包含关系。它们有交集,但也各自有特别的地方。 ... -
HotSpot Server Compiler与data-flow analysis
2014-01-07 17:41 0http://en.wikipedia.org/wiki/Da ... -
基于LLVM实现VM的JIT的一些痛点
2014-01-07 17:25 0同事Philip Reames Sanjoy Das http ... -
tailcall notes
2013-12-27 07:42 0http://blogs.msdn.com/b/clrcode ... -
《自制编程语言》的一些笔记
2013-11-24 00:20 0http://kmaebashi.com/programmer ... -
字符串的一般封装方式的内存布局 (1): 元数据与字符串内容,整体还是分离?
2013-11-07 17:44 22410(Disclaimer:未经许可请 ... -
字符串的一般封装方式的内存布局 (0): 拿在手上的是什么
2013-11-04 18:22 21510(Disclaimer:未经许可请 ... -
字符串的一般封装方式的内存布局
2013-11-01 12:55 0(Disclaimer:未经许可请 ... -
关于string,内存布局,C++ std::string,CoW
2013-10-30 20:45 0(Disclaimer:未经许可请 ... -
Java的instanceof是如何实现的
2013-09-22 16:57 0Java语言规范,Java SE 7版 http://docs ... -
也谈类型: 数据, 类型, 标签
2013-08-18 01:59 0numeric tower http://en.wikiped ... -
oop、klass、handle的关系
2013-07-30 17:34 0oopDesc及其子类的实例 oop : oopDesc* ... -
Nashorn各种笔记
2013-07-15 17:03 0http://bits.netbeans.org/netbea ...
相关推荐
在Java虚拟机(JVM)中,字节码通过解释器逐行执行,但当某个方法或代码块被频繁执行时,JIT编译器会介入,将其编译成本地机器码,以实现更快的执行速度。 JIT编译器的工作原理可以分为几个阶段: 1. **热点检测**...
HIR是HotSpot JIT编译器内部使用的高级中间代码表示形式。在编译过程中,字节码首先被转换成HIR。这一阶段的主要目的是对字节码进行分析,并将其转换为更高层次的抽象形式,便于后续优化。HIR包含了大量的类型信息和...
3. **JIT(Just-In-Time Compiler)**:JIT编译器是在运行时将JVM指令转化为本地机器代码的技术,通常包含在HotSpot JVM中。HotSpot有两个JIT编译器,C1和C2。C1(Client Compiler)主要用于快速启动,进行轻量级...
3. **即时编译器(JIT)**:Hotspot的一大特色是它的JIT编译器,分为Client Compiler(C1)和Server Compiler(C2)。C1适用于快速启动,而C2则专注于长期运行的性能优化。JIT编译器会识别并编译经常执行的“热点”...
JIT编译器将字节码转化为机器码,以提高执行速度,同时具备逃逸分析、循环展开等优化手段。 2. **垃圾收集(Garbage Collection, GC)** Hotspot的GC策略包括Serial、Parallel、Concurrent Mark Sweep (CMS) 和G1...
JIT编译器是Java虚拟机(JVM)的一部分,它的主要任务是在程序运行时将字节码转换为机器码。与传统的静态编译器不同,JIT编译器的工作方式是在运行过程中动态地进行编译,这使得它能够根据实际运行环境和数据分布...
HotSpot JVM有两个主要的JIT编译器:Client Compiler (C1) 和 Server Compiler (C2)。 - C1 编译器通常用于轻量级客户端应用,它快速生成本地代码,但优化程度较低。 - C2 编译器则用于服务器端应用,它会进行更...
解释器能够快速启动程序,而JIT编译器则负责在运行时将频繁执行的热点代码编译为本地机器码,以提高性能。HotSpot中的C1和C2编译器分别代表轻量级和重量级的JIT编译器,它们对代码进行不同程度的优化。 JIT编译器的...
6. 编译优化:HotSpot的服务器模式(Server Mode)下,JIT编译器会进行多种优化,如逃逸分析、标量替换、循环展开等。这些优化技术的源码实现,是理解Java性能提升的关键。 深入研究HotSpot源码,不仅可以提高我们...
6. **性能优化**:虽然Java编译器通常将代码转换为字节码,但现代JVM如HotSpot可以进行即时编译(JIT),将热点代码编译为机器码以提高运行时性能。Java小型Basic编译器可能利用这样的特性来提升Basic程序的执行效率...
首先,Hotspot JVM的核心设计理念是“热Spot”优化,即通过动态分析代码执行情况,识别出经常执行的“热点”代码,然后对其进行JIT(Just-In-Time)编译,生成高效的本地机器码。这种优化策略显著提升了Java应用的...
在Java虚拟机(JVM)中,HotSpot是Oracle公司的一款高性能JVM实现,它包含两个主要的Just-In-Time(JIT)编译器:C1(也称为Client Compiler)和C2(也称为Server Compiler)。这篇博客文章《给HotSpot client ...
为解决这一问题,JIT编译器应运而生,它在代码运行过程中,当确定某段代码将要频繁执行时,将其编译为机器码。这种惰性编译策略减少了启动时的编译时间,提升了运行时性能。 JIT编译器并非一次性编译所有代码,而是...
HotSpot VM中的JIT编译器是其性能优化的关键,它能够动态地选择热点代码进行优化,并将其转换为高效的机器代码。JIT编译器的主要任务包括: - **代码选择**:选择需要编译的代码片段。 - **代码优化**:进行循环展开...
Oracle公司计划在未来版本的JDK中整合这两种虚拟机的优势特性,例如使用JRockit的垃圾回收机制和Mission Control服务,同时保留HotSpot的JIT编译器和混合运行时系统。 #### 二、Java内存结构 Java内存模型主要包括...
解释器负责快速启动和轻量级执行,而JIT编译器会监控运行时数据,识别出经常执行的"热点"代码并进行编译,以达到更高效的执行速度。HotSpot VM还包括了两种类型的JIT编译:标准编译用于长时间运行的方法,而OSR编译...
例如,可以看到循环优化、内联策略、标量替换等JIT编译器的特性。 总之,掌握在Mac上使用JITWatch查看JDK 1.8的汇编代码是一项实用的技能,它可以帮助我们更好地理解Java应用程序的内部工作原理,进行性能调优,...
在Java的HotSpot虚拟机中,即时编译器(JIT,Just-In-Time Compiler)扮演着关键角色,它负责将字节码转换为机器码以提高程序的运行效率。HotSpot包含两种即时编译器:客户端编译器(C1)和服务器端编译器(C2)。C1...
尤其是在分析JIT编译器如何优化代码时,hsdis-amd64.dll提供了宝贵的洞察力。 使用hsdis-amd64.dll通常涉及到以下几个步骤: 1. **配置环境**:首先,你需要确保你的Java环境已经正确设置,包括JDK的安装和环境...
4. **JIT编译器**: - **Javac**是前端编译器,将源代码编译为字节码。 - **JIT**是HotSpot虚拟机的后端编译器,运行时将字节码编译为机器码,提高执行效率。分为Client端和Server端,以适应不同场景的需求。 ...