JIT技术是JVM中最重要的核心模块之一。我的课程里本来没有计划这一篇，但因为不断有朋友问起，Java到底是怎么运行的？既然Hotspot是C++写的，那Java是不是可以说运行在C++之上呢？为了澄清这些概念，我才想起来了加了这样一篇文章，算做番外篇吧。
Just In Time
Just in time编译，也叫做运行时编译，不同于 C / C++ 语言直接被翻译成机器指令，javac把java的源文件翻译成了class文件，而class文件中全都是Java字节码。那么，JVM在加载了这些class文件以后，针对这些字节码，逐条取出，逐条执行，这种方法就是解释执行。
还有一种，就是把这些Java字节码重新编译优化，生成机器码，让CPU直接执行。这样编出来的代码效率会更高。通常，我们不必把所有的Java方法都编译成机器码，只需要把调用最频繁，占据CPU时间最长的方法找出来将其编译成机器码。这种调用最频繁的Java方法就是我们常说的热点方法（Hotspot，说不定这个虚拟机的名字就是从这里来的）。
这种在运行时按需编译的方式就是Just In Time。
主要技术点
其实JIT的主要技术点，从大的框架上来说，非常简单，就是申请一块既有写权限又有执行权限的内存，然后把你要编译的Java方法，翻译成机器码，写入到这块内存里。当再需要调用原来的Java方法时，就转向调用这块内存。
我们看一个例子：
#include<stdio.h>
int inc(int a) {
return a + 1;
}
int main() {
printf("%d\n", inc(3));
return 0;
}
上面这个例子很简单，就是把3加1，然后打印出来，我们通过以下命令，查看一下它的机器码：
# gcc -o inc inc.c
# objdump -d inc
然后在这一堆输出中，可以找到 inc 方法最终被翻译成了这样的机器码：
40052d: 55 push %rbp
40052e: 48 89 e5 mov %rsp,%rbp
400531: 89 7d fc mov %edi,-0x4(%rbp)
400534: 8b 45 fc mov -0x4(%rbp),%eax
400537: 83 c0 01 add $0x1,%eax
40053a: 5d pop %rbp
40053b: c3 retq
我来解释一下（读者需要一定的x86汇编语言的知识）。
第一句，保存上一个栈帧的基址，并把当前的栈指针赋给栈基址寄存器，这是进入一个函数的常规操作。我们不去管它。
第三句，把edi存到栈上。在x64处理器上，前6个参数都是使用寄存器传参的。第一个参数会使用rdi，第二个参数使用 rsi，等等。所以 edi 里存的其实就是第一个参数，也就是整数 3，为什么使用rdi的低32位，也就是 edi 呢？因为我们的入参 a 是 int 型啊。大家可以换成 long 型看看效果。
第四句，把上一步存到栈上的那个整数再存进 eax 中。
第五句往后，把 eax 加上 1， 然后就退栈，返回。按照x64的规定（ABI），返回值通过eax传递。
我们看到了，其实第三句，第四句好像根本没有存在的必要，gcc 默认情况下，生成的机器码有点傻，它总要把入参放到栈上，但其实，我们是可以直接把参数从 rdi 中放入到 rax 中的。不满意。那我们可以自己改一下，让它更精简一点。怎么做呢？答案就是运行时修改 inc 的逻辑。
#include<stdio.h>
#include<memory.h>
#include<sys/mman.h>
typedef int (* inc_func)(int a);
int main() {
char code[] = {
0x55, // push rbp
0x48, 0x89, 0xe5, // mov rsp, rbp
0x89, 0xf8, // mov edi, eax
0x83, 0xc0, 0x01, // add $1, eax
0x5d, // pop rbp
0xc3 // ret
};
void * temp = mmap(NULL, sizeof(code), PROT_WRITE | PROT_EXEC,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
memcpy(temp, code, sizeof(code));
inc_func p_inc = (inc_func)temp;
printf("%d\n", p_inc(7));
return 0;
}
在这个例子中，我们使用了 mmap 来申请了一块有写权限和执行权限的内存，然后把我们手写的机器码拷进去，然后使用一个函数指针指向这块内存，并且调用它。通过这种方式我们就可以执行这一段手写的机器码了。
运行一下看看：
# gcc -o inc inc.c
# ./inc
8
再回想一下这个过程。我们通过手写机器码把原来的 inc 函数代替掉了。在新的例子中，我们是使用程序中定义的数据来重新造了一个 inc 函数。这种在运行的过程创建新的函数的方式，就是JIT的核心操作。
解释器，C1和C2
在Hotspot中，解释器是为每一个字节码生成一小段机器码，在执行Java方法的过程中，每次取一条指令，然后就去执行这一个指令所对应的那一段机器码。256条指令，就组成了一个表，在这个表里，每一条指令都对应一段机器码，当执行到某一条指令时，就从这个表里去查这段机器码，并且通过 jmp 指令去执行这段机器码就行了。
这种方式被称为模板解释器。
模板解释器生成的代码有很多冗余，就像我们上面的第一个例子那样。为了生成更精简的机器码，我们可以引入编译器优化手段，例如全局值编码，死代码消除，标量展开，公共子表达式消除，常量传播等等。这样生成出来的机器码会更加优化。
但是，生成机器码的质量越高，所需要的时间也就越长。JIT线程也是要挤占Java 应用线程的资源的。所以C1是一个折衷，编译时间既不会太长，生成的机器码的指令也不是最优化的，但肯定比解释器的效率要高很多。
如果一个Java方法调用得足够频繁，那就更值得花大力气去为它生成更优质的机器码，这时就会触发C2编译，c2是一个运行得更慢，但却能生成更高效代码的编译器。
由此，我们看到，其实Java的运行，几乎全部都依赖运行时生成的机器码上。所以，对于文章开头的那个问题“Java是运行在C++上的吗？”，大家应该都有自己的答案了。这个问题无法简单地回答是或者不是，正确答案就是Java的运行依赖模板解释器和JIT编译器。
多说一点优化
我们这节课所举的例子中，可以做更多的优化，例如，既然我进到inc函数以后，完全没有使用栈，那其实，我就不要再为它开辟栈帧了。所以可以把push rbp, pop rbp的逻辑都去掉。
进一步优化成这样：
char code[] = {
0x89, 0xf8, // mov edi, eax
0x83, 0xc0, 0x01, // add $1, eax
0xc3 // ret
};
可以看到，指令更加精简了。我们重新编译运行，还是能成功打印出8。
根据这个问题：为什么 lea 会被用来计算？
我们还可以写出更优化的代码来：
char code[] = {
0x8d, 0x47, 0x01, // lea 0x1(rdi), rax
0xc3 // ret
};
如果开启 gcc 的优化编译，我们也可以得到这样的代码，例如，还是针对这个方法：
int inc(int a) {
return a + 1;
}
使用 -O2 优化：
# gcc -o inc inc.c -O2
# objdump -d inc
就可以看到，inc 的机器码变成这样了：
00000000004005f0 <inc>:
4005f0: 8d 47 01 lea 0x1(%rdi),%eax
4005f3: c3 retq
这和我们手写的优化的机器码是完全一样的了。
实际上，C1和C2所要做的和gcc的优化编译是一样的，就是使用特定的方法生成更高效的机器码。但是从原理上来说，运行时生成机器码这个技术，大家都是相通的。
最后，补充一句，iOS禁掉了JIT编译，所用的手段就是无法申请一块同时具有写权限和执行权限的内存。那么，JIT的核心基石，运行时生成可执行的机器码就无法存在了。
