为什么JVM堆栈和Dalvik VM寄存器是基于的？

我很好奇，为什么Sun决定基于JVM堆栈，而Google决定基于DalvikVM寄存器

我认为JVM不能真的假设目标平台上有一定数量的寄存器可用，因为它应该是独立于平台的。因此，它只是将寄存器分配等延迟到JIT编译器。（如果我错了，请纠正我。）

所以安卓的人想，“嘿，这太没效率了，让我们马上去注册一个基于虚拟机…”？但是等等，有多个不同的android设备，Dalvik的目标是多少个寄存器？Dalvik操作码是否针对特定数量的寄存器进行硬编码

---

目前市场上所有安卓设备的注册数量都差不多吗？或者，在dex加载期间是否执行了寄存器重新分配？所有这些是如何结合在一起的？

基于堆栈的虚拟机有几个属性非常适合Java的设计目标：

基于堆栈的设计很少会产生错误 关于目标的假设 硬件（寄存器、CPU功能）， 因此，在虚拟机上实现虚拟机很容易 硬件种类繁多

因为指令的操作数 对象在很大程度上是隐式的 代码将趋向于更小。这 如果你想成为 缓慢下载代码 网络链接

使用基于寄存器的方案可能意味着Dalvik的代码生成器不必为生成高性能代码而努力工作。在极富或极差的建筑上运行可能会妨碍Dalvik，但这不是通常的目标——ARM是一种非常中庸的建筑

---

---

我还忘了Dalvik的初始版本根本不包括JIT。如果要直接解释指令，那么基于寄存器的方案可能是解释性能的赢家。

我不知道Sun为什么决定基于JVM堆栈。由于性能原因，BEAM基于寄存器。由于性能原因，Dalvik似乎也是基于寄存器的

发件人：

Dalvik主要使用寄存器作为数据存储单元，而不是堆栈。谷歌希望因此减少30%的指令量

关于代码大小：

Dalvik VM获取生成的Java类文件，并将它们组合成一个或多个Dalvik可执行文件（.dex）文件。它重用了来自多个类文件的重复信息，有效地将空间需求（未压缩）从传统的.jar文件中减少了一半。例如，Android中web浏览器应用程序的.dex文件约为200k，而等效的未压缩.jar版本约为500k。闹钟的.dex文件大约是50k，在.jar版本中大约是这个文件的两倍

---

正如我记得的那样，我还得出结论，注册机比基于堆栈的机器性能更好。

我找不到参考资料，但我认为Sun决定采用基于堆栈的字节码方法，因为它可以使JVM在寄存器较少的体系结构（例如IA32）上运行更容易

在《来自Google I/O 2008》中，Dalvik creator给出了以下参数，用于在的幻灯片35中选择基于寄存器的虚拟机：

登记机

为什么?

• 避免指令调度
• 避免不必要的内存访问
• 高效使用指令流（每条指令的语义密度更高）

在幻灯片36中：

登记机

统计数据

• 指令减少30%
• 代码单位减少35%
• 指令流中的字节数增加35%
  • 但我们一次要消耗两个

根据Bornstein的说法，这是“当您将一组类文件转换为dex文件时所能找到的一般期望”

报告的相关部分

---

还有一篇很有见地的论文，题目是，它探讨了基于堆栈和基于寄存器的虚拟机之间的区别。

好的，这很有趣。那么DalvikVM是否假设目标设备上的寄存器数量最少？此外，我还了解到一些人正在笔记本电脑上安装Android，因为它是一个“轻量级”操作系统。。。如果笔记本电脑不是ARM的话，这似乎是个坏主意，也许它的体系结构有很多寄存器？好吧，我刚刚了解到dex字节码是用无限寄存器机定义的，而说到效率，它似乎主要是关于内存占用。我不记得Dalvik是否基于无限寄存器，或者具有固定的寄存器文件大小。如果它是无限的，那么它将倾向于在具有“足够”寄存器的体系结构上以最佳方式执行您正在运行的任何代码。这里可以找到更详细的解释：如果我不得不猜测，我会说Sun决定基于JVM堆栈，因为它比注册机更容易实现。（但是，正如这里所指出的，性能代价非常高。）我找不到参考资料，但我认为Sun决定采用基于堆栈的字节码方法，因为它可以使JVM在低寄存器体系结构上运行变得容易。对于硬件ISA，是的，寄存器机器已经赢了。基本上，每个CPU/微控制器都是一个寄存器机器，因为相比之下，其他一切都很糟糕。有些只有很少的寄存器，比如一个累加器和一个或两个指针或索引寄存器，但这更像是计算理论意义上的寄存器机器。但是我们讨论的是被解释的虚拟机，所以如果有“寄存器文件”，那么“寄存器文件”实际上就在内存中。除非JIT编译为本机代码。reg比stack快的原因是非常不同的。这是谷歌决定让DalvikVM注册为基础的吗？我认为DalvikVM是在谷歌收购安卓公司之前实施的。你当然是对的。（虽然与问题不太相关；）