- 浏览: 459427 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
mrshen:
很棒,在其他大神的博客上理清了思路看懂之后,来lz这里用例子学 ...
RED-BLACK(红黑)树的实现TreeMap源码阅读 -
a939639017:
yanf4j check不下来 ?
Java nio 2.0 AIO -
hellostory:
又是抄来的 - -
mysql分表方案 -
davidluoye:
为什么不说下支持的数据库呢?
模糊查询的优化 -
oliveevilo:
表示没看懂
Synchronized和java.util.concurrent.locks.Lock的区别
可能许多人都读到过资料,听说过在Sun的HotSpot VM里,client VM与server VM是共用一套解释器的。那么“照理说”无论是在client还是server模式,纯解释执行的性能应该是一样的。
引用
(图片来源:The Java HotSpot Performance Engine Architecture)
是这样的么?解释器虽然是同一个,但它却可以根据启动参数的不同而变得不同。
而且有很多因素会影响测试时间的小程序(microbenchmark)。解释器自身的性能是一点,VM里其它部分的情况又是一点,例如说GC。
昨天有朋友提到这样的问题:
引用
你好,前几天看了你的JVM分享的ppt,感觉收获颇多。看完后自己写了些代码测试,其中关于JVM启动参数对性能测试的影响方面,有个问题搞不懂,就是下面两种启动参数的设置,有什么不同:
引用
Command prompt代码
1.java -client -Xint
2.
3.java -server -Xint
我预想是没有差别的,因为都是解释执行,但测试时,发现第二种比第一种要快,难道client和server两种模式下,解释器的实现不一样?望赐教。我的测试代码如下:
Java代码
1.import java.util.Calendar;
2.
3.public class Main {
4. public static String getLastDayOfMonth(String yyyyMM, boolean addZero) {
5. Calendar calendar = Calendar.getInstance();
6. calendar.set(Integer.parseInt(yyyyMM.substring(0, 4)),
7. Integer.parseInt(yyyyMM.substring(4, 6)) - 1, 1);
8. calendar.add(Calendar.MONTH, 1);
9. calendar.add(Calendar.DAY_OF_MONTH, -1);
10. String day = "" + calendar.get(Calendar.DAY_OF_MONTH);
11. if (addZero && day.length() == 1) {
12. day = "0" + day;
13. }
14.
15. return day;
16. }
17.
18. public static void main(String[] args) {
19. for(int i = 0; i < 100000; i++) {
20. Main.getLastDayOfMonth("198503", true);
21. }
22.
23. long t1 = System.currentTimeMillis();
24. for(int i = 0; i < 100000; i++) {
25. Main.getLastDayOfMonth("198503", true);
26. }
27. long t2 = System.currentTimeMillis();
28. System.out.println(t2 - t1);
29. }
30.}
在我的机器上,client模式下执行是15.5秒左右,server模式是13秒左右,试了很多次,都是这样。
java -client -Xint与java -server -Xint,事实上这两种条件下由HotSpot VM最终生成出来的解释器代码确实不是完全一样的。
先前发过的JVM分享的PPT里也有提到,HotSpot VM的解释器是在启动的时候才动态生成的,其中好处之一就是它会根据启动参数来生成最小量必要的代码(理论上…)。这样生成出来的解释器就可以在当时的环境中最合适。
在client模式中,VM参数ProfileInterpreter默认是false,而在server模式中这个参数默认为true。
生成的解释器代码中,ProfileInterpreter对应一段额外的逻辑去收集profile数据,为了给JIT编译器提供更准确的信息做更高效的优化。例如说,开启了ProfileInterpreter之后,解释器的条件跳转字节码的处理逻辑里就会多了一段,记录到底有多少次是走了then分支,而多少走了else分支(准确来说是记录条件跳转的taken与not-taken)。可以参考一下TemplateTable::branch(bool is_jsr, bool is_wide)看看这是如何实现的。
所以server模式下的解释器应该比client模式下慢。
朋友继续问:
引用
RednaxelaFX 写道
为了给JIT编译器提供更准确的信息做更高效的优化,所以server模式下的解释器应该比client模式下慢
启动参数中已经设置了-Xint,是不是说程序会一直按解释执行,如果是的话,貌似就没有必要为JIT进行信息收集了。
还有,你说的ProfileInterpreter这个参数要如何设置,是使用-D吗?
嗯,虽说设定了纯解释模式之后HotSpot VM是没必要为JIT编译器收集profile数据,但现实是HotSpot的VM参数所控制到的点并不总是那么全面,而且参数众多,有些看起来相关的参数实际上影响了不同部分的代码。
前面提到的ProfileInterpreter的默认值就只受client/server VM的区别所影响,在client VM中它默认为false,在server VM中它默认为true。
-Xint等同于几个VM参数的组合;它只是确保了UseInterpreter参数为true,却并不关心ProfileInterpreter的值如何。
可以参考Arguments::set_mode_flags(Mode mode)的逻辑,看看-Xint、-Xmixed与-Xcomp到底设定了一些什么参数。
像这样的VM参数,在HotSpot中是通过启动时在命令行传入-XX:前缀加上参数名以及参数值来设定的。布尔类型的参数是在参数名之前写+或-来表示true或false。
例如说,要强制将ProfileInterpreter参数设置为true,可以在启动Java的命令行参数上加上-XX:+ProfileInterpreter。
HotSpot的VM参数也可以通过写一个.hotspotrc配置文件来指定。它就是个普通文本文件,每行写一个参数,参数不需要-XX:前缀。如果要指定ProfileInterpreter为true并且UseCompiler为true,则文件内容为:
.hotspotrc代码
1.+ProfileInterpreter
2.+UseCompiler
该配置文件放在启动Java进程的工作目录(working directory)中。
-D是用来传递一些值给Java进程设定它的系统属性(system properties)的。多数系统属性都可以在Java程序中通过System.getProperties()获取。这跟VM参数是两个概念。
=================================================================
下面就开头的测试代码具体分析一下。环境是JDK 6 update 24 x86。
用-XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter参数可以看到实际生成出来的解释器代码(需要hsdis插件):
java -client -Xint https://gist.github.com/924905
java -server -Xint https://gist.github.com/924901
可以留意比较一下两个版本里的解释器的代码差异,例如说ifeq,client版里的就明显比server版里的短。
两者的参数差异可以在这里看:https://gist.github.com/924906
可以留意几个,
VM参数
client
server
UseInterpreter
true
true
UseCompiler
false
false
ProfileInterpreter
false
true
UseOnStackReplacement
false
false
UseLoopCounter
false
false
BackgroundCompilation
true
true
实际运行一下那段测试代码的话,可以看到:
Command prompt代码
1.[sajia@sajia ~]$ java -client -Xint Main
2.9825
3.[sajia@sajia ~]$ java -client -Xint Main
4.9820
5.[sajia@sajia ~]$ java -client -Xint Main
6.9816
7.[sajia@sajia ~]$ java -server -Xint Main
8.9519
9.[sajia@sajia ~]$ java -server -Xint Main
10.9439
11.[sajia@sajia ~]$ java -server -Xint Main
12.9446
确实在我的测试机器上跑也是server模式的更快一些。但这个测试确实只反映了解释器自身的性能么?让我们再多看些数据。
实际上问题是出在GC算法上。client模式默认是用UseSerialGC,是单线程串行执行的;而server模式默认是用UseParallelGC,是多线程并行执行的,所以server模式的会快一些(按单位回收的空间大小来算,不要按单次停机时间来算因为堆大小可能不同)。
另外堆大小的默认选择也不同,server模式默认会用更大的GC堆,所以GC次数会比较少。
看下面的日志:
Command prompt代码
1.[sajia@sajia ~]$ java -client -Xint -XX:+PrintGCDetails Main
2.[GC [DefNew: 4416K->161K(4928K), 0.0020070 secs] 4416K->161K(15872K), 0.0020790 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
3.[GC [DefNew: 4577K->160K(4928K), 0.0011860 secs] 4577K->160K(15872K), 0.0012290 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
4.[GC [DefNew: 4576K->160K(4928K), 0.0009230 secs] 4576K->160K(15872K), 0.0009630 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
5.[GC [DefNew: 4576K->160K(4928K), 0.0008960 secs] 4576K->160K(15872K), 0.0009350 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
6.[GC [DefNew: 4576K->160K(4928K), 0.0010020 secs] 4576K->160K(15872K), 0.0010450 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
7.[GC [DefNew: 4576K->160K(4928K), 0.0009180 secs] 4576K->160K(15872K), 0.0009610 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
8.[GC [DefNew: 4576K->160K(4928K), 0.0007820 secs] 4576K->160K(15872K), 0.0008220 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
9.[GC [DefNew: 4576K->160K(4928K), 0.0007600 secs] 4576K->160K(15872K), 0.0007970 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
10.[GC [DefNew: 4576K->160K(4928K), 0.0009750 secs] 4576K->160K(15872K), 0.0010160 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
11.[GC [DefNew: 4576K->160K(4928K), 0.0007790 secs] 4576K->160K(15872K), 0.0008170 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
12.[GC [DefNew: 4576K->160K(4928K), 0.0007540 secs] 4576K->160K(15872K), 0.0007900 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
13.[GC [DefNew: 4576K->160K(4928K), 0.0009090 secs] 4576K->160K(15872K), 0.0009490 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
14.[GC [DefNew: 4576K->160K(4928K), 0.0007940 secs] 4576K->160K(15872K), 0.0008310 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
15.[GC [DefNew: 4576K->160K(4928K), 0.0007470 secs] 4576K->160K(15872K), 0.0007840 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
16.[GC [DefNew: 4576K->160K(4928K), 0.0007630 secs] 4576K->160K(15872K), 0.0008010 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
17.[GC [DefNew: 4576K->0K(4928K), 0.0010530 secs] 4576K->160K(15872K), 0.0011120 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
18.[GC [DefNew: 4480K->0K(4992K), 0.0003780 secs] 4640K->160K(15936K), 0.0004160 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
19.[GC [DefNew: 4480K->0K(4992K), 0.0001560 secs] 4640K->160K(15936K), 0.0001920 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
20.[GC [DefNew: 4480K->0K(4992K), 0.0001450 secs] 4640K->160K(15936K), 0.0001800 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
21.[GC [DefNew: 4480K->0K(4992K), 0.0001430 secs] 4640K->160K(15936K), 0.0001790 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
22.[GC [DefNew: 4480K->0K(4992K), 0.0001420 secs] 4640K->160K(15936K), 0.0001780 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
23.[GC [DefNew: 4480K->0K(4992K), 0.0001480 secs] 4640K->160K(15936K), 0.0001840 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
24.[GC [DefNew: 4480K->0K(4992K), 0.0001680 secs] 4640K->160K(15936K), 0.0002080 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
25.[GC [DefNew: 4480K->0K(4992K), 0.0001700 secs] 4640K->160K(15936K), 0.0002070 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
26.[GC [DefNew: 4480K->0K(4992K), 0.0001540 secs] 4640K->160K(15936K), 0.0001890 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
27.9841
28.Heap
29. def new generation total 4992K, used 1974K [0xbf710000, 0xbfc70000, 0xc4c60000)
30. eden space 4480K, 44% used [0xbf710000, 0xbf8fd8c0, 0xbfb70000)
31. from space 512K, 0% used [0xbfbf0000, 0xbfbf0000, 0xbfc70000)
32. to space 512K, 0% used [0xbfb70000, 0xbfb70000, 0xbfbf0000)
33. tenured generation total 10944K, used 160K [0xc4c60000, 0xc5710000, 0xcf710000)
34. the space 10944K, 1% used [0xc4c60000, 0xc4c881c8, 0xc4c88200, 0xc5710000)
35. compacting perm gen total 12288K, used 34K [0xcf710000, 0xd0310000, 0xd3710000)
36. the space 12288K, 0% used [0xcf710000, 0xcf718948, 0xcf718a00, 0xd0310000)
37. ro space 10240K, 61% used [0xd3710000, 0xd3d38a38, 0xd3d38c00, 0xd4110000)
38. rw space 12288K, 60% used [0xd4110000, 0xd4848ec0, 0xd4849000, 0xd4d10000)
39.
40.[sajia@sajia ~]$ java -server -Xint -XX:+PrintGCDetails Main
41.[GC [PSYoungGen: 14016K->198K(16320K)] 14016K->198K(53696K), 0.0024550 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
42.[GC [PSYoungGen: 14214K->174K(16320K)] 14214K->174K(53696K), 0.0016880 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
43.[GC [PSYoungGen: 14190K->174K(16320K)] 14190K->174K(53696K), 0.0013630 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
44.[GC [PSYoungGen: 14190K->174K(16320K)] 14190K->174K(53696K), 0.0017030 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
45.[GC [PSYoungGen: 14190K->174K(13888K)] 14190K->174K(51264K), 0.0014890 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
46.[GC [PSYoungGen: 13870K->174K(13568K)] 13870K->174K(50944K), 0.0017340 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
47.[GC [PSYoungGen: 13550K->16K(13120K)] 13550K->178K(50496K), 0.0018910 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
48.[GC [PSYoungGen: 13072K->0K(12864K)] 13234K->162K(50240K), 0.0007120 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
49.9482
50.Heap
51. PSYoungGen total 12864K, used 3073K [0xe1e30000, 0xe2dd0000, 0xf4230000)
52. eden space 12800K, 24% used [0xe1e30000,0xe21306d8,0xe2ab0000)
53. from space 64K, 0% used [0xe2dc0000,0xe2dc0000,0xe2dd0000)
54. to space 256K, 0% used [0xe2d50000,0xe2d50000,0xe2d90000)
55. PSOldGen total 37376K, used 162K [0xbd630000, 0xbfab0000, 0xe1e30000)
56. object space 37376K, 0% used [0xbd630000,0xbd6588c8,0xbfab0000)
57. PSPermGen total 16384K, used 1937K [0xb9630000, 0xba630000, 0xbd630000)
58. object space 16384K, 11% used [0xb9630000,0xb98146f8,0xba630000)
能看出区别来了么?
然后朋友回复:
引用
刚才我又试了一下,设置相同的堆大小,都用并行垃圾收集后,两者的运行时间基本一致(但貌似你机器的配置要比我好很多 ),如下:
Command prompt代码
1.C:\eclipse\workspace\JITTest\bin>java -client -Xint -Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m -XX:+UseParallelGC -XX:+PrintGCDetails Main
2.[GC [PSYoungGen: 15168K->240K(17664K)] 15168K->240K(259648K), 0.0017866 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
3.[GC [PSYoungGen: 15408K->208K(17664K)] 15408K->208K(259648K), 0.0011884 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
4.[GC [PSYoungGen: 15376K->224K(17664K)] 15376K->224K(259648K), 0.0009685 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
5.[GC [PSYoungGen: 15392K->224K(17664K)] 15392K->224K(259648K), 0.0009029 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
6.[GC [PSYoungGen: 15392K->224K(17664K)] 15392K->224K(259648K), 0.0009185 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
7.[GC [PSYoungGen: 15392K->208K(19904K)] 15392K->208K(261888K), 0.0010813 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
8.[GC [PSYoungGen: 19856K->16K(19712K)] 19856K->220K(261696K), 0.0011097 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
9.12782
10.Heap
11.PSYoungGen total 19712K, used 3160K [0x28280000, 0x29630000, 0x2a9e0000)
12. eden space 19648K, 16% used [0x28280000,0x285921b0,0x295b0000)
13. from space 64K, 25% used [0x295b0000,0x295b4000,0x295c0000)
14. to space 320K, 0% used [0x295e0000,0x295e0000,0x29630000)
15.PSOldGen total 241984K, used 204K [0x0a9e0000, 0x19630000, 0x28280000)
16. object space 241984K, 0% used [0x0a9e0000,0x0aa13060,0x19630000)
17.PSPermGen total 65536K, used 2470K [0x029e0000, 0x069e0000, 0x0a9e0000)
18. object space 65536K, 3% used [0x029e0000,0x02c49828,0x069e0000)
19.
20.C:\eclipse\workspace\JITTest\bin>java -server -Xint -Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m -XX:+UseParallelGC -XX:+PrintGCDetails Main
21.[GC [PSYoungGen: 21952K->240K(25536K)] 21952K->240K(258560K), 0.0016271 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
22.[GC [PSYoungGen: 22192K->208K(25536K)] 22192K->208K(258560K), 0.0011813 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
23.[GC [PSYoungGen: 22160K->224K(25536K)] 22160K->224K(258560K), 0.0009733 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
24.[GC [PSYoungGen: 22176K->224K(25536K)] 22176K->224K(258560K), 0.0009282 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
25.[GC [PSYoungGen: 22176K->224K(25536K)] 22176K->224K(258560K), 0.0009107 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
26.12798
27.Heap
28.PSYoungGen total 25536K, used 4176K [0x28140000, 0x29db0000, 0x2ba20000)
29. eden space 21952K, 18% used [0x28140000,0x2851c170,0x296b0000)
30. from space 3584K, 6% used [0x296b0000,0x296e8040,0x29a30000)
31. to space 256K, 0% used [0x29d70000,0x29d70000,0x29db0000)
32.PSOldGen total 233024K, used 0K [0x0ba20000, 0x19db0000, 0x28140000)
33. object space 233024K, 0% used [0x0ba20000,0x0ba20000,0x19db0000)
34.PSPermGen total 65536K, used 2470K [0x03a20000, 0x07a20000, 0x0ba20000)
35. object space 65536K, 3% used [0x03a20000,0x03c89828,0x07a20000)
呵呵,确实如此。
因为解释器本来就比较慢,所以增加ProfileInterpreter并不会显著的增加开销,所以这部分开销才可以接受。但非要追究谁快谁慢的话,那还是client模式下默认生成的解释器会比server模式的快一些的。
发表评论
-
JDK内置工具使用(转)
2012-08-09 10:56 1188JDK内置工具使用 一、javah命令(C Header a ... -
jstack使用
2012-08-09 10:37 1535Java综合 我们使用jdk自带的jstack来分析。当lin ... -
jstat使用
2012-08-09 09:51 1120如何判断JVM是否存在内 ... -
java应用crash案例
2012-08-08 22:05 1193最近,应用总会时不时c ... -
一个java crash的故障分析过程
2012-08-08 22:01 2246一个应用在周五 ... -
Java进程Crash的故障分析方法(转)
2012-08-08 21:54 4911I、Java进程无故退出的 ... -
使用CORE DUMP
2012-08-08 20:59 1666程序出现SIGSEGV ,Segmenta ... -
( 转)JVM执行篇:使用HSDIS插件分析JVM代码执行细节
2012-08-08 20:10 928在《Java虚拟机规范》之 ... -
Java Crash问题分析
2012-08-05 18:36 1901如果是Java进程不知道 ... -
JVM性能优化
2012-04-26 10:30 1092本文主要根据这篇PDF(G ... -
Java编译器、JVM、解释器
2012-04-25 16:43 2980Java 虚拟机(JVM)是可运行 ... -
JVM执行篇:使用HSDIS插件分析JVM代码执行细节
2012-04-10 13:27 1293在《Java虚拟机规范》之 ... -
IcedTea在开源与OpenJDK的鸿沟上架起了桥梁
2011-11-22 23:54 16912008-06-12 18:06 作者: 来源:来自论坛 [ ... -
Sun的JDK7、OpenJDK及IcedTea释疑
2011-11-22 23:44 1247http://www.infoq.com/cn/news/20 ... -
在XUbuntu 10.10上以JRL源码构建Oracle JDK 6 update 23
2011-11-22 23:00 1913http://rednaxelafx.iteye.com/bl ... -
n JDK 和 OpenJDK 的区别
2011-11-22 13:34 2214http://hi.baidu.com/openware/bl ... -
线程局部存储Thread Local Storage-TLS(总结整理)
2011-10-27 18:18 1729在线程的学习中我们知道每个线程除了共享进程的资源外还拥有各 ... -
c++阿里笔试
2011-10-26 14:43 16631、有一个虚拟存储系统 ... -
GDB调试精粹及使用实例
2011-10-12 14:41 979一:列文件清单 1. List (gdb) list li ... -
Mercurial学习笔记
2011-10-11 13:06 6649录 •1 Mercurial 一览: 基础 ◦1.1 ...
相关推荐
Troubleshooting Guide for Java SE 6 with HotSpot VM
The Java HotSpot VM.pdf
jvm参数介绍,oracle HotSpot官方参数文档。
HotSpot正是目前世界上java虚拟机的最好的实现。 HotSpot的基础代码是许多人辛勤劳动的结晶,这个过程迄今已持续了超过10年的时间(当然时间长并不意味着一定好,一半一半吧)。所以到现在为止,他的体积是很大的。...
官方完整版JVM源码Hotspot VM,文件名hotspot.tar.gz。官方完整版JVM源码Hotspot VM,文件名hotspot.tar.gz。
HotSpot VM 是目前市面上高性能JVM 的代表作之一,它采用解释器+JIT 编译器的混合执行引擎,使得Java 程序的执行性能从此有了质的飞跃。《Java虚拟机精讲》以极其精练的语句诠释了HotSpot VM 的方方面面,比如:字节...
It will be set after the class is loaded.VM Started: Set deferred breakpoint Tes
本书深入浅出地讲解了 HotSpot 虚拟机的工作原理,将隐藏在它内部的本质内容逐一呈现在读者面前,包 括 OpenJDK 与 HotSpot 项目、编译和调试 HotSpot 的方法、HotSpot 内核结构、Launcher、OOP-Klass 对象表 示系统...
它来源于Strongtalk VM, 而这款虚拟机中相当多的技术又是来源于一款支持Self语言实现“达到C语言50%以上的执行效率”的目标而设计的虚拟机, Sun公司注意到了这款虚拟机在JIT编译上有许多优秀的理念和实际效果,...
[inside hotspot] 汇编模板解释器(Template Interpreter)和字节码执行1
深入Hotspot源码与Linux内核理解NIO与Netty线程模型
DR版回答是:t1在存Java静态变量的地方, 概念上在JVM的方法区(method area)里t2在Java堆里, 作为Test的一个实例的字段存在t3在J
HotSpot VM 是目前市面上高性能JVM 的代表作之一,它采用解释器+JIT 编译器的混合执行引擎,使得Java 程序的执行性能从此有了质的飞跃。本书以极其精练的语句诠释了HotSpot VM 的方方面面,比如:字节码的编译原理、...
HotSpot VM 是目前市面上高性能JVM 的代表作之一,它采用解释器+JIT 编译器的混合执行引擎,使得Java 程序的执行性能从此有了质的飞跃。本书以极其精练的语句诠释了HotSpot VM 的方方面面,比如:字节码的编译原理、...
将隐藏在它内部的本质内容逐一呈现在读者面前,包括OpenJDK与HotSpot项目、编译和调试HotSpot的方法、HotSpot内核结构、Launcher、OOP-Klass对象表示系统、链接、运行时数据区、方法区、常量池和常量池Cache、Perf ...
提起HotSpot VM,相信所有Java程序员都知道,它是Sun JDK和OpenJDK中所带的虚拟机,也是目前使用范围最广的Java虚拟机。
実装》第4章4.4小节. 每个版本的算法描述都稍微不同,我的伪代码也跟这两本书写的方式稍微不同,但背后要表达的核心思想是一样的就OK了.Tracing GC
DR版回答是:t1在存Java静态变量的地方, 概念上在JVM的方法区(method area)里t2在Java堆里, 作为Test的一个实例的字段存在t3在J
技术文档分享。