JVM为什么采用面向操作数栈而不是寄存器的架构？

写在前面

本文隶属于专栏《100个问题搞定Java虚拟机》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和文献引用请见100个问题搞定Java虚拟机

解答

Java是最早提出一次编译四处运行的计算机语言。
为了支持这种跨平台的特性，只有面向操作数栈的指令集架构才能满足需求。

补充

基于栈的指令集与基于寄存器的指令集

Java编译器输出的指令流，基本上是一种基于栈的指令集架构(Instruction Set Architecture，ISA)，指令流中的指令大部分都是零地址指令，它们依赖操作数栈进行工作

使用“基本上”，是因为部分字节码指令会带有参数，而纯粹基于栈的指令集架构中应当全部都是零地址指令，也就是都不存在显式的参数。Java这样实现主要是考虑了代码的可校验性。

与之相对的另外一套常用的指令集架构是基于寄存器的指令集，最典型的就是x86的二地址指令集，说得通俗一些，就是现在我们主流PC机中直接支持的指令集架构，这些指令依赖寄存器进行工作。

基于栈的指令集与基于寄存器的指令集有什么区别？

举个最简单的例子，分别使用这两种指令集计算“1+1”的结果，基于栈的指令集会是这样子的:

iconst_1
iconst_1
iadd 
istore_0 

两条iconst_1指令连续把两个常量1压人栈后，iadd指令把栈顶的两个值出栈、相加， 然后把结果放回栈顶，最后istore_0把栈顶的值放到局部变量表的第0个Slot中。

如果基于寄存器，那程序可能会是这个样子:

move eax,  1
add eax, 1

mov指令把EAX寄存器的值设为1，然后ad指令再把这个值加1，结果就保存在EAX寄存器里面。

基于栈的指令集与基于寄存器的指令集哪个好一点？

应该这么说，既然两套指令集会同时并存和发展，那肯定是各有优势的，如果有一套指令集全面优于另外一套的话，就不会存在选择的问题了。

基于栈的指令集优点

基于栈的指令集主要的优点就是可移植，寄存器由硬件直接提供，程序直接依赖这些硬件寄存器则不可避免地要受到硬件的约束。

例如，现在32位80x86体系的处理器中提供了8个32位的寄存器，而ARM体系的CPU(在当前的手机、PDA中相当流行的一种处理器)则提供了16个32位的通用寄存器。
如果使用栈架构的指令集，用户程序不会直接使用这些寄存器，就可以由虚拟机实现来自行决定把一些访问最频繁的数据(程序计数器、栈顶缓存等)放到寄存器中以获取尽量好的性能，这样实现起来也更加简单一些。

栈架构的指令集还有一些其他的优点，如代码相对更加紧凑(字节码中每个字节就对应一条指令，而多地址指令集中还需要存放参数)、编译器实现更加简单(不需要考虑空间分配的问题，所需空间都在栈上操作)等。

基于栈的指令集缺点

栈架构指令集的主要缺点是执行速度相对来说会稍慢一些。所有主流物理机的指令集都是寄存器架构也从侧面印证了这一点。

虽然栈架构指令集的代码非常紧凑，但是完成相同功能所需的指令数量一般会比寄存器架构多，因为出栈、入栈操作本身就产生了相当多的指令数量。
更重要的是，栈实现在内存之中，频繁的栈访问也就意味着频繁的内存访问，相对于处理器来说，内存始终是执行速度的瓶颈。

尽管虚拟机可以采取栈顶缓存的手段，把最常用的操作映射到寄存器中避免直接内存访问，但这也只能是优化措施而不是解决本质问题的方法。
由于指令数量和内存访问的原因，所以导致了栈架构指令集的执行速度会相对较慢。

这里说的是物理机器上的寄存器，也有基于寄存器的虚拟机，如Google Android平台的Dalvik VM。即使是基于寄存器的虚拟机，也希望把虚拟机寄存器尽量映射到物理寄存器上以获取尽可能高的性能。