LEC15: 用户程序的虚拟内存操作原语

要点总结

  1. 操作系统应该为用户控制的虚拟内存提供更好的支持: 更快,更正确,更完整.
  2. 会让用户程序运行的更快.
  3. 允许通过虚拟内存实现一些巧妙的机制
  4. 提供了使用的示例清单
  5. 分析了OS的虚拟内存使用效率,认为尚有足够的优化空间.
  6. 他们是否定义了新的虚拟内存接口或设计或实现？

内存操作原语

  1. TRAP, PROT1, PROTN, UNPROT, DIRTY, MAP2

PROTN的实际操作

  1. 将PTE/TLB标记为保护状态
  2. 将OS的虚拟内存管理结构体标记为保护状态
  3. 设置硬件PTE/TLB缓存的状态为无效,强制刷新.

TRAP的实际含义

  1. 将PTE/TLB标记为保护状态
  2. CPU保存用户进程上下文,接着陷入内核.
  3. 内核向虚拟内存系统询问要做什么?从磁盘读入一个页,还是发生了core dump?
  4. 产生一个signal,向上调用用户程序.新的函数栈可能处于用户栈之下,也可能是一个新的函数栈.

  5. 执行用户注册的signal处理函数:

    5.1 可能是调用UNPROT取消特定页的保护

    5.2 也可能去修改发生异常的内存地址

  6. signal处理函数返回内核态
  7. 内核态返回用户态
  8. 重新执行导致异常发生的指令

内存操作原语在1991的OS中,是否可用?

貌似大部分可用,只有DEC 3100硬件不支持MAP2.

操作原语快吗?

  1. 快的含义是什么?

    1.1 可能是相对于编译器产生的检查代码?

    1.2 可能是相对于即将运行的中断处理函数?

  2. 当前的速度 在1.2GHz的Athlon机器上,FreeBSD4.3,执行trap,unprot,prot耗时约12微秒

是否必须要硬件来支持这些原语?

  1. 不会导致安全问题,所有可以由用户态控制
  2. 为什么不使用精简指令集的思想?

  3. 为什么不使用编译器自动生成代码来模拟虚拟内存?

    3.1 或许可能模拟,但是修改编译器是非常痛苦的工作

  4. CPU已经有了虚拟内存相关的硬件,为什么不使用它?

    4.1 实现代码必须和硬件相关,因此移植性下降

    4.2 在一些廉价的CPU上,没有虚拟内存相关的硬件

  5. 对大多数人而言,使用虚拟内存要比hack编译器容易多了

并发的内存回收

  1. 双空间复制的内存回收机制?

    1.1 需要将旧空间的指针和已拷贝标志位复制

    1.2 为什么吸引人?分配方便(TODO)

    1.3 有什么缺点?

  2. Baker的增长GC?

    2.1 新空间的已扫描区域

    2.2 从新空间的未扫描区域读取内容必须检查,是否指回旧空间

    2.3 对于复制的对象,必须将转发指针留在from空间中

  3. 虚拟内存是否有帮助?

    3.1 通过设置未扫描区域为读保护,避免显式的检查从from space返回的ptr.

    3.2 为什么不将from space设置为读保护?

    3.3 如果一个并行的回收进程运行在另一个CPU上,为什么不会冲突?

    3.4 回收进程只需要读取from-space,并且保护to-space的未扫描区域

    3.5 当分配进程陷入内核,需要同步

已有的虚拟内存原语对并发内存回收足够好了吗?

  1. MAP2是唯一可能有功能性问题的,然而并不是.我们从来也不需要访问同一页面两次.

  2. trap足够快了么?

    2.1 扫描一个内存页需要500us,处理一次trap需要1200us.

results matching ""

    No results matching ""