# 17.6 使用虚拟内存特性的GC

论文中介绍，如果拥有了前面提到的虚拟内存特性，你可以使用虚拟内存来减少指针检查的损耗，并且以几乎零成本的代价来并行运行GC。这里的基本思想是将heap内存中from和to空间，再做一次划分，每一个部分包含scanned，unscanned两个区域。在程序启动，或者刚刚完成了from和to空间的切换时，整个空间都是unscanned，因为其中还没有任何对象。

之后的过程与前面描述的相同，在开始GC时，我们将根节点对象拷贝到to空间，但是根节点中的指针还是指向了位于from空间的对象。现在unscanned区域包括了所有的对象（注，现在只有根节点），我们会将unscanned区域的权限设置为None。这意味着，当开始GC之后，应用程序第一次使用根节点，它会得到Page Fault，因为这部分内存的权限为None。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MXHu4HEdXjDAboyKtwv%2F-MXKMam7kkK9NXXLe6Tq%2Fimage.png?alt=media\&token=463cba49-6f7e-4b4b-8003-662a81cba504)

在Page Fault Handler中，GC需要扫描位于内存Page中所有的对象，然后将这些对象所指向的其他对象从from空间forward到to空间。所以，在GC最开始的时候，我们将根节点拷贝过来了；之后在Page Fault Handler中通过扫描，将根节点指向的对象也都拷贝过来了。在我们的例子中根节点指向的只有两个对象，这两个对象会被拷贝到unscanned区域中，而根节点会被标记成scanned。在我们扫描完一个内存Page中的对象时，我们可以通过Unprot（注，详见17.1）恢复对应内存Page的权限。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MXHu4HEdXjDAboyKtwv%2F-MXKOp_19tpLHWC8OUKB%2Fimage.png?alt=media\&token=68a446a6-1af8-4480-aef3-00ad016c5827)

之后，应用程序就可以访问特定的对象，因为我们将对象中的指针转换成了可以安全暴露给应用程序的指针（注，因为这些指针现在指向了位于to空间的对象），所以应用程序可以访问这些指针。当然这些指针对应的对象中还没有被扫描。如果dereference这些指针，我们会再次得到Page Fault，之后我们会继续扫描。

这种方案的好处是，它仍然是递增的GC，因为每次只需要做一小部分GC的工作。除此之外，它还有额外的优势：现在不需要对指针做额外的检查了（注，也就是不需要查看指针是不是指向from空间，如果是的话，将其forward到to空间）。或者说指针检查还在，只是现在通过虚拟内存相关的硬件来完成了。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MXHu4HEdXjDAboyKtwv%2F-MXKQ7kqHZ5FjwrxSMDY%2Fimage.png?alt=media\&token=bed34faa-ff16-4ae9-921f-460beb182108)

> 学生提问：刚刚说到在Handler里面会扫描一个Page中的所有对象，但是对象怎么跟内存Page对应起来呢？
>
> Frans教授：在最开始的时候，to空间是没有任何对象的。当需要forward的时候，我刚刚描述的是拷贝一个对象，但是实际上拷贝的是一个内存Page中的N个对象，这样它们可以填满整个Page。所以现在我们在to空间中，有N个对象位于一个Page中，并且它们都没有被扫描。之后某个时间，Page Fault Handler会被调用，GC会遍历这个内存Page上的N个对象，并检查它们的指针。对于这些指针，GC会将对应的对象拷贝到to空间的unscanned区域中。之后，当应用程序使用了这些未被扫描的对象，它会再次得到Page Fault，进而再扫描这些对象，以此类推。
>
> 学生提问：在完成了GC之后，会切换from和to空间吗？
>
> Frans教授：最开始我们使用的是from空间，当用完了的时候，你会将对象拷贝到to空间，一旦完成了扫描，from空间也被完全清空了，你可以切换两个空间的名字。现在会使用to空间来完成内存分配。直到它也满了，你会再次切换。

论文中提到使用虚拟内存的另一个好处是，它简化了GC的并发。GC现在可以遍历未被扫描的内存Page，并且一次扫描一个Page，同时可以确保应用程序不能访问这个内存Page，因为对于应用程序来说，未被扫描的内存Page权限为None。虚拟内存硬件引入了这种显式的同步机制，或者说对于抢占的保护。

现在只有GC可以访问未被扫描的内存Page，而应用程序不能访问。所以这里提供了自动的并发，应用程序可以运行并完成它的工作，GC也可以完成自己的工作，它们不会互相得罪，因为一旦应用程序访问了一个未被扫描的Page，它就会得到一个Page Fault。而GC也永远不会访问扫描过的Page，所以也永远不会干扰到应用程序。所以这里以近乎零成本获取到了并发性。

但是实际上有个麻烦的问题。回到我们之前那张图，我们在heap中有from空间，to空间。在to空间中又分为了unscanned和scanned区域，对于应用程序来说，unscanned区域中的Page权限为None。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MXHu4HEdXjDAboyKtwv%2F-MXKaJ-arpm5Z8NwQ-6p%2Fimage.png?alt=media\&token=d4aca8af-42ee-42a9-9795-3a96caf5bc22)

这就引出了另一个问题，GC怎么能访问这个区域的内存Page？因为对于应用程序来说，这些Page是inaccessible。

这里的技巧是使用map2（注，详见17.1）。这里我们会将同一个物理内存映射两次，第一次是我们之前介绍的方式，也就是为应用程序进行映射，第二次专门为GC映射。在GC的视角中，我们仍然有from和to空间。在to空间的unscanned区域中，Page具有读写权限。

![](https://1977542228-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MHZoT2b_bcLghjAOPsJ%2F-MXHu4HEdXjDAboyKtwv%2F-MXKcehw4uGK40AzyHr9%2Fimage.png?alt=media\&token=e6bd6cc4-85c6-41ca-9537-50e14a58036a)

所以GC可以遍历这些内存Page，读取内容并forward必要的对象。这里使用了map2将物理内存映射到应用程序地址空间中两次的能力，其中每次映射都有不同的权限，这样这里的场景才能工作。

> 学生提问：GC和应用程序是不是有不同的Page Table？
>
> Frans教授：不，它们拥有相同的Page Table。它们只是将物理内存映射到了地址空间的两个位置，也就是Page Table的两个位置。在一个位置，PTE被标记成invalid，在另一个位置，PTE被标记成可读写的。