MM(内存管理)沉思录.docVIP

MM沉思录（一） ——扯淡 内存对于任何计算设备都是非常重要的资源。因此，如何对它进行有效的管理也是非常重要的。由于Linux的出现与大幅度流行，很多真正喜欢计算机软件的程序员都有机会对OS的内部实现进行学习和研究。所以，我相信，到目前为止，已经有不计其数的IT技术人员知道Linux的内存管理是如何设计和实现的。 我就是其中之一。在学习和研究的过程中，我一直试图去理解问题的本质，尝试跳出Linux之外来看待内存管理的真正面目。按照我一贯的风格，我认为，只有抓住了这些，你才可以避免被那些让人眼花缭乱的细节耗去你宝贵的精力，才可以让自己有限的记忆力容纳更多的真正有价值的东西。更近一步，只有抓住了这些，你才可能会发现问题的所在，才可能去做真正意义上的创新。 我想通过这篇文章，对带有MMU的、支持分页方式虚拟内存的平台上的操作系统的内存管理思想进行推理式的讨论。从而说明当前你所看到的内存管理算法和架构为什么是这个样子。 由于内存模型会影响OS的设计，以及Application的Link/Load方式。我们在谈到某种内存模型的时候，会从这两个方面讨论某种模型的特点。 希望我能够把自己对MM的理解写的足够清楚……MM沉思录（二） ——简史 远古时代,整个系统只有一个地址空间,即物理地址空间。无论操作系统还是应用程序看到的都是这个地址空间，它们共同来使用它。 这对于单任务的OS没有什么问题。OS占据其中的一部分，把其余的部分留给应用程序，编译器或链接器负责把应用程序的入口地址设定为固定位置，把其它段，如Data段，Stack段等等根据程序本身的规模放到应用程序可使用空间的某个位置。在执行的时候，Loader把这些段放到相应的位置，如果实际的物理内存不足以容纳当前的Application，OS就直接给出错误信息．否则，执行它就是了。 但对于多任务的OS，其Application的Link/Loader模型就不是那么简单了。由于多个Application共享供应用程序使用的地址空间，那么每个Application在每次执行时被装入内存的位置可能是不同的。那么这个Application里面的地址访问指令——如果不是明确的想访问某个绝对地址的话——就绝对不能将绝对地址明确的指出来。否则，运行时一定会出问题。 这些地址只能是相对地址。解决运行时问题的方法之一是：编译器／链接器对于每个非程序员明确指出的地址都编译为一个未赋值地址加上一个相对地址。在执行的时候，Loader根据当前Application被装入的实际地址对这个未赋值基地址进行赋值。这样，Application的每一个地址访问指令给出的就都是正确的绝对地址了。 这种方法肯定可以工作，但却存在着一个很大的性能问题，由于Application对于每个内存的访问都要先进行地址运算，而内存访问在一个程序的执行过程中是非常频繁的，其性能可想而知。 所以，硬件设计者根据这个问题提出了分段模式．分段模式允许程序在指定了某个段的基地址之后，随后程序给出的地址都是相对于这个段基地址的相对地址．对于绝对地址的运算由硬件完成，性能自然高多了。编译器／链接器在编译链接的时候，只需要认为自己所使用的地址是从０开始的。Loader在装载程序的时候，只需要把OS分配给当前Application的内存设定为一个段就可以了。 本质上，分段模型将一维的地址空间变成了二维．因为在同一物理地址空间内可以有任意数量的段，每个段内的地址都是［0，limit_of_segment-1]。这样，无论是OS，还是Application在给出一个地址的时候，这个地址都不是绝对的物理地址，而是其在某个段内的地址。硬件会负责把这些段内的相对地址转化为物理绝对地址。 段模型曾经让我感到困惑的一点是段与段之间可以重叠．所以可以重叠，使指两个段空间对应的物理地址有交集。当时我觉得，如果段与段之间可以重叠的话，你对于一个段的访问可能会修改另外一个段的数据。我之所以感到困惑，是因为我没有完全理解段模型的真正意义．段模型提供给OS和Application一种访问内存的方式，让程序员可以在一个段空间任意直接指定地址。在两个段空间内访问到共同的绝对物理地址与段模型本身的意义完全没有任何矛盾和冲突。 尽管有了分段机制，但所有的段内相对地址都会被直接映射为绝对物理地址。所有的Application的所有代码和数据，在运行时刻都被装载在物理内存内。 另外，尽管分段机制允许段与段之间可以重叠，但如果不是为了某些特殊目的，比如进程间共享数据，不同Application之间的段是不应该重叠的。 所以，Application程序员在写程序时，需要考虑对内存的使用，因为总体的内存是非常有限的，如果其占用的内存过多，留给系统中别的Application自然就少。有时候，某个Ap