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 -version
java 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代码的性能，经常会出现结果失真。