RE:循环语句的写法、Client和Server的性能差异以及microbenchmark的不准确
这篇文章也是个回帖，继续用来偷懒发blog
=====================================================
一位朋友给了下面这段代码(在他给的代码中略作修改，避免了引入Random类、Integer装箱类导致不必要的因素)，提出了2个问题：1.for (int i = 0, n = list.size(); i < n; i++)的写法是否会比for (int i = 0; i < list.size(); i++)更快？2.为何这段代码在Server VM下测出来的速度比Client VM还慢？
public class Client1 {public static void main(String[] args) {List<Object> list = new ArrayList<Object>();Object obj = new Object();// 填充数据for (int i = 0; i < 200000; i++) {list.add(obj);}long start;start = System.nanoTime();// 初始化时已经计算好条件for (int i = 0, n = list.size(); i < n; i++) {}System.out.println("判断条件中计算：" + (System.nanoTime() - start) + " ns");start = System.nanoTime();// 在判断条件中计算for (int i = 0; i < list.size(); i++) {}System.out.println("判断条件中计算：" + (System.nanoTime() - start) + " ns");}}首先来看看在代码最终执行时，for (int i = 0, n = list.size(); i < n; i++)的写法是否会比for (int i = 0; i < list.size(); i++)更快，用于测试的虚拟机是：
D:\_DevSpace\jdk1.7.0\fastdebug\bin>java -versionjava version "1.7.0-ea-fastdebug"Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b127)Java HotSpot(TM) Client VM (build 20.0-b06-fastdebug, mixed mode)
调试参数就加了一个-XX:+PrintAssembly，用于输出JIT后的汇编代码，虚拟机默认是Client。
for (int i = 0, n = list.size(); i < n; i++)的循环体是
0x01fcd554: inc %edx ; OopMap{[60]=Oop off=245} ;*if_icmplt ; - Client1::main@63 (line 17) 0x01fcd555: test %eax,0x1b0100 ; {poll} 0x01fcd55b: cmp %eax,%edx ;; 124 branch [LT] [B5] 0x01fcd55d: jl 0x01fcd554 ;*if_icmplt ; - Client1::main@63 (line 17)变量i放在edx中，变量n放在eax中，inc指令对应i++（其实被优化成++i了），test指令是在回边处进行safepoint轮询（safepoint是用于进入GC，停顿线程），cmp是比较n和i的值，jl就是当i<n的时候进行跳转，跳转的地址是回到inc指令。
for (int i = 0; i < list.size(); i++)的循环体是：
0x01b6d610: inc %esi ;; block B7 [110, 118] 0x01b6d611: mov %esi,0x50(%esp) 0x01b6d615: mov 0x3c(%esp),%esi 0x01b6d619: mov %esi,%ecx ;*invokeinterface size ; - Client1::main@113 (line 23) 0x01b6d61b: mov %esi,0x3c(%esp) 0x01b6d61f: nop 0x01b6d620: nop 0x01b6d621: nop 0x01b6d622: mov $0xffffffff,%eax ; {oop(NULL)} 0x01b6d627: call 0x01b2b210 ; OopMap{[60]=Oop off=460} ;*invokeinterface size ; - Client1::main@113 (line 23) ; {virtual_call} 0x01b6d62c: nop ; OopMap{[60]=Oop off=461} ;*if_icmplt ; - Client1::main@118 (line 23) 0x01b6d62d: test %eax,0x160100 ; {poll} 0x01b6d633: mov 0x50(%esp),%esi 0x01b6d637: cmp %eax,%esi ;; 224 branch [LT] [B8] 0x01b6d639: jl 0x01b6d610 ;*if_icmplt ; - Client1::main@118 (line 23)可以看到，除了上面原有的几条指令外，确实还多了一次invokeinterface方法调用（这里发生了方法调用，但是基本上没有分派的开销，因为inline cache是能起作用的），执行的方法是size，方法接收者是list对象，除此之外，其他指令都和上面的循环体一致。所以至少在HotSpot Client VM中，第一种循环的写法是能提高性能的。
但是这个结论并不是所有情况都能成立，譬如这里把list对象从ArrayList换成一个普通数组，把list.size()换成list.length。那将可以观察到两种写法输出的循环体是完全一样的（都和前面第一段汇编的循环一样），因为虚拟机不能保证ArrayList的size()方法调用一次和调用N次是否会产生不同的影响，但是对数组的length属性则可以保证这一点。也就是for (int i = 0, n = list.length; i < n; i++)和for (int i = 0; i < list.length; i++)的性能是没有什么差别的。
再来看看ServerVM和ClientVM中这2段代码JIT后的差别，本想直接对比汇编代码，但ServerVM经过Reordering后，代码就完全混乱了，很难和前面的比较，不过我们还是可以注意到两者编译过程的不同：
这是Client VM的编译过程
VM option '+PrintCompilation' 169 1 java.lang.String::hashCode (67 bytes) 172 2 java.lang.String::charAt (33 bytes) 174 3 java.lang.String::indexOf (87 bytes) 179 4 java.lang.Object::<init> (1 bytes) 185 5 java.util.ArrayList::add (29 bytes) 185 6 java.util.ArrayList::ensureCapacityInternal (26 bytes) 186 1% Client1::main @ 21 (79 bytes)
这是Server VM的编译过程
VM option '+PrintCompilation' 203 1 java.lang.String::charAt (33 bytes) 218 2 java.util.ArrayList::add (29 bytes) 218 3 java.util.ArrayList::ensureCapacityInternal (26 bytes) 221 1% Client1::main @ 21 (79 bytes) 230 1% made not entrant Client1::main @ -2 (79 bytes) 231 2% Client1::main @ 51 (79 bytes) 233 2% made not entrant Client1::main @ -2 (79 bytes) 233 3% Client1::main @ 65 (79 bytes)
ServerVM中OSR编译发生了3次，丢弃了其中2次（made not entrant的输出），换句话说，就是main()的每个循环JIT编译器都要折腾一下子。当然这并不是ServerVM看起来比ClientVM看起来慢的唯一原因。ServerVM的优化目的是为了长期执行生成尽可能高度优化的执行代码，为此它会进行各种努力：譬如丢弃以前的编译成果、在解释器或者低级编译器（如果开启多层编译的话）收集性能信息等等，这些手段在代码实际执行时是必要和有效的，但是在microbenchmark中就会显得很多余并且有副作用。因此写microbenchmark来测试Java代码的性能，经常会出现结果失真。
正好你在用fastdebug版，可以加个-XX:+TraceICs来看看。
HotSpot client compiler只利用了CHA来做虚方法调用的优化，而JDK初始化的时候就会加载ArrayList和LinkedList，从CHA来看List接口有多个实现，所以无法只通过CHA证明list.size()只有单一可能调用的目标，就只能用inline cache而不能inline了。
你想说第一种更快吧…
话说你的编译日志和帖出来的源码不对应嘛。行号对不上 = =import java.util.ArrayList;import java.util.List;public class Client2 {public static void doTest() {List<Object> list = new ArrayList<Object>();Object obj = new Object();// 填充数据for (int i = 0; i < 1000000; i++) {list.add(obj);}long start;start = System.nanoTime();// 初始化时已经计算好条件for (int i = 0, n = list.size(); i < n; i++) {}System.out.println("判断条件中计算：" + (System.nanoTime() - start) + " ns");start = System.nanoTime();// 在判断条件中计算for (int i = 0; i < list.size(); i++) {}System.out.println("判断条件中计算：" + (System.nanoTime() - start) + " ns");} public static void main(String[] args) {doTest();doTest();doTest();}}
Icy再来分析分析看？
提示：正文里client compiler没把list.size()内联掉，结合这个Client2版本来看又如何呢？猜猜看是什么东西导致了差异？
关键词有两个，一个是三个字母的缩写，另一个是“phi”
;; block B8 [118, 121] 0x00bbe448: inc %esi ; OopMap{edi=Oop [48]=Oop off=1017} ;*goto ; - Client2::doTest@121 (line 22) 0x00bbe449: test %eax,0x970100 ;*goto ; - Client2::doTest@121 (line 22) ; {poll} ;; block B7 [107, 115] 0x00bbe44f: mov 0xc(%edi),%ecx ;*getfield size ; - java.util.ArrayList::size@1 (line 177) ; - Client2::doTest@110 (line 22) 0x00bbe452: cmp %ecx,%esi ;; 240 branch [LT] [B8] 0x00bbe454: jl 0x00bbe448 ;*if_icmpge ; - Client2::doTest@115 (line 22)这是Client2的“第二个版本”的for循环的循环体被标准编译后生成的代码。分析交给你了 ^_^
嗯顺便一提，这种情况下仍然是“第一种”的代码快些。不过差别比Client1里看到的状况小多了。
list没挂啊。那段代码里%edi就是list局部变量分配到的寄存器。
0xc(%edi)
这用Intel语法写就是
[edi + c]
也就是
[list + #offset_of_size_field]
换回成Java语法那就是
list.sizeList<Object> list = flag ? new LinkedList<Object>() : new ArrayList<Object>();
对应的doTest()改为doTest(boolean flag)，JIT的输出就立即变成：
0x0267df4c: inc %esi ;; block B10 [124, 132] 0x0267df4d: mov %esi,0x5c(%esp) 0x0267df51: mov 0x40(%esp),%eax 0x0267df55: mov %eax,%ecx ;*invokeinterface size ; - Client2::doTest@127 (line 24) 0x0267df57: mov %eax,0x40(%esp) 0x0267df5b: nop 0x0267df5c: nop 0x0267df5d: nop 0x0267df5e: mov $0xffffffff,%eax ; {oop(NULL)} 0x0267df63: call 0x0263b210 ; OopMap{[64]=Oop off=1080} ;*invokeinterface size ; - Client2::doTest@127 (line 24) ; {virtual_call} 0x0267df68: nop ; OopMap{[64]=Oop off=1081} ;*if_icmplt ; - Client2::doTest@132 (line 24) 0x0267df69: test %eax,0x200100 ; {poll} 0x0267df6f: mov 0x5c(%esp),%esi 0x0267df73: cmp %eax,%esi ;; 256 branch [LT] [B11] 0x0267df75: jl 0x0267df4c ;*if_icmplt又变回了老样子，因为这时候虚拟机已经无法推断出list的实际类型了，alright，那我猜那3个字母的组合是“Exact Type Inference”——精确类型推断。
List<Object> list = flag ? new LinkedList<Object>() : new ArrayList<Object>(); 那在标准编译中，list的类型也无法精确推断出来。
由HotSpot client compiler在OSR编译时转换为HIR之后的控制流图：
这B1前的入口就是真正带来差异的点。OSR入口使得B1的开头不得不带上了若干个phi节点，破坏了原本的类型信息的准确性。