13. The Abstraction: Address Spaces

13.1 Early Systems

• 从内存的角度来说，早期的机器并没有提供很多的抽象给用户，因此比较简单，如下图：

13.2 Multiprogramming and Time Sharing

• 因为早期机器很贵，因此有了Multiprogramming的需求，需要充分利用CPU。
• 欲望是无穷的，人们又有了Time Sharing的需求。人与机器的交互也变得很重要，你不想机器不理你对吧。
• 如何实现Time Sharing呢？比较简单的方式是，让一个进程上CPU，并且给它内存所有的使用权限。运行一会后，停止运行，保存当前的所有信息到磁盘上，然后换下一个进程上来。这种方式当然可以，但是不够elegant，so crude！
• 问题就在于太慢啦！虽然保存寄存器信息很快，但是还有别的保存是很耗时的。所以我们要做的是让所有进程都保留在内存中，有效实现time sharing。如下图：

• 问题又来了，多进程都在内存中，如何做到protection？一个进程不能读别的进程的内容吧，也不能修改吧。

13.3 The Address Space

• 解决方法是对物理内存进行抽象，我们把这种抽象叫做Address Space。理解地址空间，就要理解是如何虚拟化内存的。
• Address Space包含了运行程序的所有内存状态。主要是：
  • code：即程序的代码，指令集。
  • stack：用于保存所有的局部变量、参数和返回值等。
  • heap：保存动态分配的内存。
  • 其他
• 如下图就是一个Address Space：

• stack和heap一个从上往下，一个从下往上，这种做法并不是固定的。
• 在Address Space中，地址是从0KB到16KB的，但其实它并不是指真正物理内存的0KB到16KB。那么问题就来了，OS如何才能建立起这种对内存抽象呢？
• 建立抽象其实就是OS在虚拟化内存，OS这样做会让运行的程序认为，它真的被加载到物理内存的0KB到16KB了（经典欺骗进程）。举个栗子，当进程A试图从地址0开始加载时，其实并不是真的物理内存的0，而是它的地址空间的0，那么OS就要和硬件联手，把这个地址空间的0对应到物理内存的320KB去（因为A真的放在这）。

13.4 Goals

• 虚拟化内存，我们要达到以下几个目标：
• 第一，虚拟内存（VM）系统是透明的，也就是说对程序是不可见的。程序意识不到自己的空间是假的，意识不到它的0不是真的0。
• 第二，VM的效率。OS应该尽可能的提高虚拟的效率，这就要靠硬件的支持了。
• 第三，保护。OS应该保护进程的信息不被其他进程读写，同样也应该保护OS的内存不被其他进程读写。也就是说各进程之间要隔离开来。

13.5 Summary

• VM系统提供大的、私人的地址空间给程序，用于保存进程自己的信息。
• OS可以连同硬件一起，将虚拟的地址转化为物理地址。
• OS还对不同进程提供保护，提供隔离性。
• 未完待续