目标机的内存管理

目标机的内存管理

要允许目标机的binaries在不同平台执行，未必需要重新编译文件。如果源文件是以big-endian格式编码的，且如果给定平台是little-endian，那么目标机上的Run-time应该负责相应的转换。

虚拟机要支持可移植性特征，需要在软件中实现完整的内存保护。

当目标机的Run-time被调用时，它从本地操作系统分配内存来为单个应用程序构建人工的地址空间。此地址空间确切地被分成三部分：text 部分、heap 部分、stack 部分。地址依次从低到高，text部分起始地址为0。
在编译时test部分的地址是固定的，而stack和heap部分的地址大小是可调节的。

虚拟机支持命令行选项，允许调整stack和heap的尺寸，要求是非负值。运行时还检查确定stack不会溢出到heap部分，或溢出到被禁止的地址空间顶部。

保护本地平台要做的另一件事是，固定一定数量的有效内存到地址空间。一旦分配了text、heap和stack地址后，立刻做这件事。Unix系统使用sbrk()函数。

当虚拟机初始载入一个应用程序到内存，它做一次性检查，确定程序的binary编码指令的合法性。这种一次性检查就是字节码校验（Bytecode Verification）。虚拟机检查看指令操作数是否有正确的值，还检查确定地址符号没有越界，所有的指令操作代码均有效。

要消除内存延迟（Memory Latency）造成的一些危险，最好是把Run-time载入到物理内存。在目标机建立地址空间之前，目标机做一个调用，查看空闲的物理内存大小，如果有效的物理内存不足，则虚拟机不启动。

最为复杂的是heap管理。可以考虑使用显示内存管理模式。理由如下：
1）大多数垃圾收集器的实现都采用了多线程环境，耗用不少CPU周期。如果目标机不是多线程环境呢？

2）虚拟机的设计目标是可移植性、简单性、高性能。类似与BDW收集器之类的保守垃圾收集器并不简单，不能马上就实现移植。从本质上讲，垃圾收集器需要run-time系统做额外的工作来跟踪已分配的内存。这些额外的工作引入了额外的指令，降低了系统性能。


机器设计

中央处理器能以基于寄存器或基于Stack的机器来实现。基于寄存器的处理器，如Intel的奔腾处理器；而基于Stack的处理器，如Harris半导体的RTX32P，它有两个片上Stack来执行基本的操作。

基于Stack的处理器在嵌入式领域往往更为流行，因为它们可支持更小的程序，更受限的资源。比如一个基于Stack的处理器指令如IADD，从Stack弹出两个整数，然后求和，并把和压入Stack，指令如下：
ADD $R1, $R2, $R3
此指令求得$R2和$R3的和，并放入$R1。
基于Stack的IADD指令只需一个单字节就可完成该工作。而基于寄存器的ADD指令至少需要四个字节。
所以显然基于Stack的机器编译程序所需的时间比基于寄存器的机器编译时间更短。

基于Stack的计算机执行函数调用也更高效。因为函数参数本身就存放在Stack内。而基于寄存器的计算机，其函数参数必须存取，并手动放入到Stack，需要做更多的工作。

基于Stack的计算机其上下文切换耗费资源也更小。而基于寄存器的计算机，上下文切换前必须手动保存所有寄存器的状态，RISC架构往往有大量的寄存器，其上下文切换需要集中内存操作。而基于Stack的计算机则没有这些问题。

并非基于寄存器的架构就一无是处，它有一个更大的优势：更快。寄存器位于CPU内，存取值操作非常块。Intel的新64处理器，如Itanium，有上百个片上寄存器，而基于Stack的处理器，几乎总是从内存存取数据，这显然比较慢。

比较表
————————————————————————————————————————————————
---------                              基于Stack的处理器                                     基于寄存器的处理器
————————————————————————————————————————————————
Benefits                             更小的内存占用                                          基本操作非常快
                                          更快的函数调用                                          （整体性能更好）
                                          更快的上下文切换                                       执行更透明
Costs                                 基本操作比较慢                                memory-intensive上下文切换
                                                                                                 work-intensive函数调用
————————————————————————————————————————————————