内存布局与内存管理方案的混淆

Question

我研究了一些操作系统的概念，有点困惑，现在有了以下问题.

执行中程序的内存布局(即。(文本、数据、堆栈、堆)只有在虚拟地址空间的上下文中才有意义？如果程序在其虚拟地址空间中被组织成这些逻辑部分，那么当地址开始使用分页或分段之类的内存管理方案从虚拟地址转换为物理地址时，这些部分不是就会变得混乱吗？

据我所知，这两种方案允许物理地址空间中的非连续分区。因此，如果我的“文本”部分在虚拟地址空间中从地址0到100 (随机选择的大小)，而我选择使用分页，并且我的页面大小是20个地址的长度(即文本部分有5页)，那么一旦这些页面被非连续地放置在物理地址空间中(基于可用的任何空闲空间)，那么文本“节”的概念是不是就不再有意义了(因为它是杂乱无章的)？

最后，分割中以物理地址空间结尾的可变大小段是否与虚拟空间中内存布局的逻辑类别(文本、数据、堆栈、堆)完全相同？这里唯一的警告是，在物理空间中，段是分散的、非连续的(不是相邻的)，但仍然在它们的特定类别(即所有的“数据”在物理空间中保持在一起/相邻)中健康地存在吗？

非常感谢您的帮助和澄清，谢谢！

Answer 1

执行中程序的内存布局(即。(文本、数据、堆栈、堆)只有在虚拟地址空间的上下文中才有意义？如果程序在其虚拟地址空间中被组织成这些逻辑部分，那么当地址开始使用分页或分段之类的内存管理方案从虚拟地址转换为物理地址时，这些部分不是就会变得混乱吗？

是这样的。这些部分在虚拟内存中是连续的，但在物理内存中不是连续的。这不是一个问题，因为操作系统维护页表；处理器的MMU使用这些表在每次访问时透明地将虚拟地址转换为物理地址，操作系统本身可以使用它们来确定要与哪些(分散的)物理页面交互，例如，进程何时结束，其内存将被回收。

据我所知，这两种方案允许物理地址空间中的非连续分区。因此，如果我的“文本”部分在虚拟地址空间中从地址0到100 (随机选择的大小)，而我选择使用分页，并且我的页面大小是20个地址的长度(即文本部分有5页)，那么一旦这些页面被非连续地放置在物理地址空间中(基于可用的任何空闲空间)，那么文本“节”的概念是不是就不再有意义了(因为它是杂乱无章的)？

节的概念仍然适用于适用虚拟地址的上下文。您的用户模式程序处理虚拟地址(即指针本质上是虚拟地址)，许多操作系统仍然处理虚拟地址。向分散的物理地址的转换是由MMU按需完成的，并且只有内核代码的一个子集需要处理物理地址。

旁白:由于页面的簿记开销，这些都是不现实的大小；典型的页面大小是4096字节，有些平台上有创建大页的方法，以进一步减少这种开销。

最后，分割中以物理地址空间结尾的可变大小段是否与虚拟空间中内存布局的逻辑类别(文本、数据、堆栈、堆)完全相同？这里唯一的警告是，在物理空间中，段是分散的、非连续的(不是相邻的)，但仍然在它们的特定类别(即所有的“数据”在物理空间中保持在一起/相邻)中健康地存在吗？

不，它们是分散在一个逐页的基础上的，并不是每个虚拟页面都会有一个物理的内存页支持。例如，由于需求寻呼，页面在实际需要时才懒洋洋地获得物理支持。尚未使用的.text页可能不会从磁盘加载，直到分页实际上诱导内核从磁盘加载它们。

同样，如果物理内存不足，未使用的页面可能会从虚拟内存中被逐出，并被放置到磁盘上；当下一次访问它们时，分页将诱导内核从磁盘加载它们。

虚拟地址也可以映射到不表示DIMM上DRAM内存物理页的物理地址。可以将虚拟地址映射到表示内存映射IO的物理地址，或者在两个进程之间共享一页虚拟内存，作为协同通信的一种形式。

为了优化，还有更多的技巧要做。例如，Linux的fork syscall不复制页面；相反，它设置页面表以启用名为抄写即写的特性，其中页面只有在父级或子级写入页面时才被复制，并且仅读取的页面在两者之间共享。