还有lz说的inline，这个对优化的重要性无可比拟，我认为java在这方面也有优势。c compiler一般以一个c文件作为一个编译单元，只能在自己可见的范围内进行inline，所以绝大部分被inline的函数需要放在头文件中，这其实要很大程度上要依赖程序员的经验。java的jit compiler可以根据实际的运行情况决定如何inline，这个不需要程序员介入而且实际的效果更好。

我也来为java说两句，java对于c/c++来说还有一个优势就是类型安全，这对别名分析(alias analysis)带来很大的好处。c语言中的数据类型可以任意转换，对于compiler来说就是一场噩梦。例如一个简单的例子
void foo( ClassA a, ClassB b ){
  x=a.f1;
  b.f2=0;
  y=a.f1;
...

假设ClassA和ClassB没有继承关系，这里java的compiler可以安全的认为a和b指向的是不同的内存，y可以直接使用x的结果，或者reorder前两句的顺序都可以由compiler根据需要决定。如果换成c语言中的指针，虽然在绝大部分情况下这两块内存不重叠，但compiler必须采用最保守的策略。

还有lz说的inline，这个对优化的重要性无可比拟，我认为java在这方面也有优势。c compiler一般以一个c文件作为一个编译单元，只能在自己可见的范围内进行inline，所以绝大部分被inline的函数需要放在头文件中，这其实要很大程度上要依赖程序员的经验。java的jit compiler可以根据实际的运行情况决定如何inline，这个不需要程序员介入而且实际的效果更好。

对于implicit null check(INC)，还有些隐含的性能损失，它导入了一些新的control dependent，而且sun的c2对于含有INC的basic block有一些特殊的约定（具体为什么不清楚），我们的jit compiler下一步打算去掉这个优化，恢复explicit null check，使用其他的技术来达到它的效果。

首先，JIT中做逃逸分析是栈上分配的基础，但不意味着有逃逸分析，就有栈上分配了，只是完成了其前提而已。你文档中也说了，栈上分配现在的状态是可以做，但事实上还没有做。

The GC efficiency afforded by Stack Allocation may [negatively] surprise most people. Eliminating allocation all-together through in-frame escape analysis (e.g. turning objects into registers) is one thing - it gives you faster programs, regardless of GC issues. However, if you actually have to allocate the thing in memory and in an object structure (which is generally the case for cross-frame situations), placing it in a thread-local area or a stack arrangement turns out to be a very small win, and if the VM is not careful about it, may often not be worth the extra processing overhead compared to bump-a-pointer contiguous heap allocation. The reason behind this is that generational collection of short lived stuff is already super-efficient, and most stack-allocatable objects are exactly the sort of objects that generational GC spends zero time on: short lived enough that they are never visited by the collector and never copied anywhere, not even to a survivor space. (read: no cost at all, except for a somewhat earlier trigger of a new-gen collection cycle through increased allocation pressure). So, if you already have to pay for allocation in one form or another, generational collection of most stack-allocatable objects is actually cheaper than dealing with stack "de-allocation" (or alternate forms of per-frame bookkeeping) of object allocation frames. Escape analysis’s relative, which we dub "escape detection" (and for which we have hardware assists in Azul machines), allows us to evaluate allocation behaviors and opportunities across frames, and can offer interesting optimizations, but the resulting GC efficiency is not nearly as big as a win as you may think. At Azul, we simply eliminate or change the question to begin with: our GCs don't stop your program, and use plentiful cores for background execution while your program threads keep executing happily. We eat GC pressure for breakfast, as in tens of GBytes per second of sustainable pauseless allocation with GC happily keeping up in the background. Taking pressure off such a collector is simply not so much an issue or a goal any more, so you can make a really big mess if you want, and focus on making your program do interesting, useful stuff... -- Gil. Azul Systems

其次，根据现有的使用报告看来，逃逸分析花费的代价并不比获取的收益小多少，花了力气分析，最后的RP不好，没找到太多确定不会逃逸的对象，虚拟机表示鸭梨很大。因此虽然逃逸分析日后肯定很有前途，但至少目前为止貌似还不太靠谱，大家反应的效果是“microbenchmarks中能跑出很好看的成绩，但实际应用，尤其是规模较大的应用中效果貌似不太好”，否则不会连C2都默认关闭它，也不会在6u18中被完全关闭掉。关于这点的论据我没有数据支持，比较心虚 ，撒迦不妨详细说一说。

第一个例子，jit是可以比静态编译器多做一次Copy Propagation优化，但以这点来证明类型安全在运行效率上也是java的优势会不会太牵强了？需要证明这点，必须拿出保证类型安全付出的代价会比保证类型安全所带来的收益小才行。

关于内联，顶楼中提出的论点是“由于java鼓励的面向对象编程，导致java虚方法使用频率远多于c++”，而不是说jit的内联优化比c++的差，事实上jit的内联应当说是相当先进，即使是虚方法jit也可以通过CHA来找出可以内联的那一部分虚方法来内联。但是这是一个开发方式导向上的问题，而不是技术上的问题，如你写了一个实体类，本来这种类不应当会有什么子类，而且都是方法调用成本大于代码执行成本，最适合内联的。但是搞不好引入Hibernate，立刻就给你动态生成了一堆子类型，jit访问的时候就迷茫了。

这里你就很明显没看清楚人家例子的用意了。CSAPP里对alias问题举例讲得不错，去读读？
这个例子最明显的地方是a.f1与b.f2在没有类型安全的保障下很有可能实际上指向了同一个存储空间，也就是形成了别名。这样编译器就不能将x的值直接用在a.f1第二次出现的地方了，因为a.f1的定义此时可能被前面的b.f2的赋值给“kill”了。

第一个例子，jit是可以比静态编译器多做一次Copy Propagation优化

void foo( ClassA a, ClassB b ){
  x=a.f1;
  b.f2=0;
  y=a.f1; 
}

void foo( ClassA a, ClassB b ){
  x=a.f1;
  b.f2=0;
  y=x;  //Copy Propagation
}

但以这点来证明类型安全在运行效率上也是java的优势会不会太牵强了？需要证明这点，必须拿出保证类型安全付出的代价会比保证类型安全所带来的收益小才行。

Hmmm……是前面这句有问题？

还是你想强调的本意是指别名问题是因，复写传播是果？