Java JIT性能瓶颈分析

What is JIT

JIT是Just In Time的简写，JIT是编译器的一种特性，他的功能是将解释执行的代码编译成mache code，从而消除解释过程开销，提升应用性能，目前支持JIT功能的语言有：Java，JavaScript，PHP， Perl， Python，Ruby，.Net等，可以说JIT是目前主流解释型语言消除先天缺陷的首选技术，与之相似的技术还有AOT，博主对AOT了解比较少，就不展开来讲啦。

How JIT apply to Java

Java应用JIT技术由来已久，总所周知Java的Code Cache在JDK8以前保存在方法区，JDK8以后挪到了堆上的元数据空间（哈哈，Java程序员面试必背的知识点），这里的Code Cache就是保存mache code的空间。Java程序执行一开始是在Interpreter的解释下执行的，每执行一次，函数的计数器就会增加一次，当函数执行次数达到一定量级时，就会被编译成machine code放到code cache，当然，在编译的过程中会涉及到一些optimization，比如inline和osr等，这里mache code分为两个级别，分别通过C1-Compiler、C2-Compiler进行编译，C2-Compiler编译后的代码将会得到巨大的性能提升。

JIT Affect

代码经过JIT编译成mache code一方面会带来巨大的性能提升，另一方面会给定位问题带来难度

public class JitTest {
    public void f1() {
        while (true) {
            f2();
        }
    }

    public void f2() {
        f3();
    }

    public void f3() {
        f4();
    }

    public void f4() {
        int i = 0;
    }

    public static void main(String[] args) {
        JitTest jitTest = new JitTest();
        jitTest.f1();
    }
}

运行上诉代码，捕获到的jstack将会是下面这种情况
上述jstack显示堆栈到f1就戛然而止了，那么f2、f3、f4函数难道没有调用吗？其实这里代码已经被compile成mache code了，compile过程中已经对代码进行了inline，所以看不到更底层的函数调用。另外一方面safepoint是函数级别的，如果没有被inline，f1、f2、f3、f4都会存在safeponit，但是inline过后只有一个safepoint了，所以当gc发生时，必须等f1、f2、f3、f4全部执行完才能进行gc，扯远啦哈哈。那么这种情况会对我们定位问题带来一些干扰，因为我们根本不知道被inline后的f1到底卡在哪里，试想f4方法内部存在一个开销很重的操作，那么我们通过jstack根本定位不到

public class JitTest {
    byte[] src = "strstrstrstrstrstrstrstrstrstrstrstrstrstrstrstrstrstrstrstr".getBytes();
    byte[] dst = new byte[src.length];
    public void f1() {
        while (true) {
            f2();
        }
    }

    public void f2() {
        f3();
    }

    public void f3() {
        f4();
    }

    public void f4() {
        int i = 0;
        System.arraycopy(src,0,dst,0,src.length);
    }

    public static void main(String[] args) {
        JitTest jitTest = new JitTest();
        jitTest.f1();
    }
}

此时jstack依然没变
通过传统的safepoint basis工具无法定位到性能瓶颈
我们借助perf + perf-map-agent + libjvmti观察得到下图
继续分析jbyte_disjoint_arraycopy native code得到
可见性能瓶颈卡在arraCopy操作的读写内存上
当然，如果我们不care machine code或者我们读不懂machine code，只想知道卡在那个函数符号上面，我们也可以借助dtrace、ebpf、system tap等os level的工具进行分析，下面是ebpf的front tool bcc的profile工具导出的堆栈一般情况下ebpf相对其他工具较为准确，能够减少抽样过程中observer effect带来的堆栈丢失，下图是bcc profile工具导出的flame graph

Summary

JIT是编译器非常不错的功能，能够大大提升程序性能，当然也要求我们在保证应用功能的前提下尽量保持clean code，借助传统工具无法定位问题，我们可以考虑更优秀的工具挖掘收集信息。