C编译器剖析_2.3 内存管理

    较复杂的C或C++程序，经常会根据其自身应用的特点，定制其内存堆空间的管理策略，UCC编译器不也例外。在第1章介绍ucc\examples\sc时，为了简单起见，我们只管使用malloc来分配堆空间，并没有去考虑堆空间释放free的问题，这对于sc这么一个简单的运行时间很短、且堆空间足够用的程序而言，不会造成什么问题，在其进程结束时，操作系统会回收相关内存。但如果长期运行的服务器程序存在内存泄露，则会造成内存分配不成功，由此引起致命错误。这也是有些服务器运行一两个月后，就会突然死机，重起后又能撑上一两个月的原因之一。在引入请求分页机制的操作系统中，内存泄露实际上指的是进程的虚地址空间已经完全被分配完了。是的，物理内存很宝贵，但内存虚地址空间也是一种宝贵的资源。在请求分页操作系统中，C程序员面对的地址实际上是虚地址，并不是实际物理内存的地址，例如，在以下代码中，”&abc”代表的是变量abc在进程虚地址空间中的地址。支持请求分页的操作系统，如Windows或Linux，已经让程序员跟物理内存说再见了。

         int  abc;

         int * ptr = &abc;

         UCC对堆空间的需求可分为这么几种情况：

    (1)分析命令行参数，初始化对寄存器的管理，设置基本的类型系统，如图2.1.3

的第191至197行所示。这部分数据在整个编译器运行期间都要存在，所以在UCC中称这部分堆空间为ProgramHeap，如第191行所示。

    (2) 在编译器编译某一个预处理后的C文件时，需要为之构建语法树和符号表，一个C文件对应一个编译单元。在编译完一个C文件后，就可以释放该文件所对应的语法树和符号表。所以这部分空间有着明显的“文件作用域”，在UCC中被称为FileHeap。如图2.1.3的第210至213行。

    (3) 在分析各个C文件中遇到的字符串及各个标志符的名称，则存放于被称StringHeap的堆空间中。

图2.1.3  main()

        

    如下所示，在分析名为abc的double类型变量时，会在StringHeap中申请堆空间来存放其变量名”abc”，再遇到名为abc的int变量，就没有必要再分配内存空间来存放变量名”abc”了。同名的各个标志符完全可以共用同一份字符串。这样做的好处是，要判断两个标志符名字是否一样时，不必进行字符串的比较，只要比较标志符对应的字符串首地址即可，例如ucl\symbol.c的 DoLookupSymbol()函数就只用了if (p->name == name)来比较两个标志符。