观察到的行为受到HotSpot优化器的影响，但这不是唯一的原因。当我运行以下代码
public static void main(String[] argv) {
System.out.println(System.getProperty("java.version"));
System.out.println(countDepth());
System.out.println(countDepth());
System.out.println(countDepth());
System.out.println(countDepth());
System.out.println(countDepth());
System.out.println(countDepth());
System.out.println(countDepth());
}
static int countDepth() {
try { return 1+countDepth(); }
catch(StackOverflowError err) { return 0; }
}
启用JIT后，我得到如下结果：
> f:\Software\jdk1.8.0_40beta02\bin\java -Xss68k -server -cp build\classes X
1.8.0_40-ea
2097
4195
4195
4195
12587
12587
12587
> f:\Software\jdk1.8.0_40beta02\bin\java -Xss68k -server -cp build\classes X
1.8.0_40-ea
2095
4193
4193
4193
12579
12579
12579
> f:\Software\jdk1.8.0_40beta02\bin\java -Xss68k -server -cp build\classes X
1.8.0_40-ea
2087
4177
4177
12529
12529
12529
12529
在这里，JIT的效果清晰可见，显然优化后的代码需要更少的堆栈空间，并且它表明启用了分层编译（实际上，-XX:-TieredCompilation如果程序运行时间足够长，则使用一次跳转）。
相反，在禁用JIT的情况下，我得到以下结果：
> f:\Software\jdk1.8.0_40beta02\bin\java -Xss68k -server -Xint -cp build\classes X
1.8.0_40-ea
2104
2104
2104
2104
2104
2104
2104
> f:\Software\jdk1.8.0_40beta02\bin\java -Xss68k -server -Xint -cp build\classes X
1.8.0_40-ea
2076
2076
2076
2076
2076
2076
2076
> f:\Software\jdk1.8.0_40beta02\bin\java -Xss68k -server -Xint -cp build\classes X
1.8.0_40-ea
2105
2105
2105
2105
2105
2105
2105
这些值仍会变化，但不会在单个运行时线程内变化，并且幅度较小。
因此，如果优化程序可以减少每次方法调用所需的堆栈空间（例如由于内联），则存在一个（相当小的）差异，该差异会变得更大。
是什么导致这种差异？我不知道这个JVM是如何做到的，但是一种情况可能是强制执行堆栈限制的方式要求对堆栈结束地址进行一定的对齐（例如，匹配内存页面大小），而内存分配返回的内存具有一个起始地址，对齐保证较弱。将这种情况与ASLR结合使用，可能在对齐要求的大小范围内始终存在差异。
602392714
清零编程群