20.7 Evaluation: HLL benefits

Biscuit的实现与其他内核，例如XV6，非常相似，除了Biscuit比XV6性能要高的多。Biscuit采用了很多Linux内核的优化和聪明的设计：

• 我们对于内核文本采用了大页，以避免TLB的代价。

• 我们有针对每个CPU的网卡队列，这样可以避免CPU核之间同步。

• 我们有RCU实现了不需要读锁的Directory Cache。

• ……

通常为了高性能而做的优化，编程语言并不会成为阻碍。Golang并没有成为阻碍这些优化实现的因素。这些优化之前是在C和Linux中实现，我们现在只是在Golang中又实现它们。在实现这些优化时有很多的工作，但是这些工作与编程语言本身无关。

今天论文的出发点就是了解用高级编程语言实现操作系统的收益和代价。所以我们将分两部分来评估，首先是收益，其次是代价。

有关高级编程语言，我们要回答三个问题：

• 首先，我们有没有作弊？或许我们避免使用了所有Golang提供的高级编程语言中代价较高的功能。

• 其次，高级编程语言是否有简化Biscuit代码？

• 最后，高级编程语言是否能阻止前面提到的内核漏洞？

首先，我们有没有使用高级编程语言的特性？我们会对比一下Biscuit与其他两个大的Golang项目在使用语言特性上是否类似，这样我们才可以说我们的内核以类似的方式利用了相同的语言特性。这里我们使用了相同的静态分析工具来分析两个大的Golang项目，它们都有超过100万行代码，其中一个项目是Go runtime以及包含的所有包，另一个是一个叫做Moby的系统。

之后我们画出了一些高级语言特性在每1000行代码中的使用量。图中X轴是语言特性：

• allocation对应于new

• maps就是hashtable

• slice是动态数组

• channel是同步的工具，如你所见我们用的很少，Go runtine和Moby也用的很少

• 很明显我们最喜欢的特性就是函数返回多个值

• 我们使用了Closure（闭包）

• 我们稍微使用了defer

• 我们使用了Interface

• 使用了Type assertion来以一种类型安全的方式将一个类型转换成另一个类型

• 同时我们也import了很多包，Biscuit内核是由很多个包构建出来的，而不是一个大的单一的程序

如你所见，有些特性Biscuit用的比Go runtime和moby更少，有些特性Biscuit用的更多，这里没有很明显的区别。所以从这张图中可以得出的主要结论是：Biscuit使用了Golang提供的高级编程语言特性，而不是为了得到好的性能而避开使用它们。

学生提问：你这里是怎么统计的？是不是使用了静态分析工具？

Frans教授：是的，这里使用的就是静态分析工具。通过写一个小程序利用静态分析工具来查看这些项目的每一行代码，并记录对应的特性是什么，这样就能统计这些特性的使用数量。

第二个问题有点主观，高级编程语言有没有简化Biscuit代码？笼统的说我认为有的，我这里会讨论一两个例子。

使用Garbage allocation是极好的，你可以回想XV6，当你调用exit时，有大量的结构化数据需要被释放回给内核，这样后面的进程才能使用。如果使用Garbage Collector这里的工作着实容易，Garbage Collector会完成这里的所有工作，你基本不用做任何事情。如果你从地址空间申请了一段内存，对应这段内存的VMA会自动被GC释放，所以这里可以简化代码。

如之前所说的，函数返回多个值对于代码风格很好。闭包很好，map也很好。XV6中很多地方通过线性扫描查找数据，但是如果你有map和hashtable作为可以直接使用的对象，那么你就不用线性扫描了。你可以直接使用map，runtime会高效地为你实现相应的功能。所以直观上的感受是，你可以得到更简单的代码。

但是前面只是定性的评估，下面会介绍一些更具体的例子。当有大量的并发线程，且线程有共享的数据时，GC如何起作用的。

这里有个最简单的例子。假设你申请了一些动态的对象，比如说buffer，你fork一个线程来处理这个buffer，原线程也会处理同一个buffer。当两个线程都完成了工作，buffer需要被释放，这样内存才可以被后面的内核代码使用。这在C语言里面有点难协调，因为你需要有某种方式来决定buffer不再被使用。如果你使用GC，那么就没什么好决定的，因为当两个线程都处理完buffer之后，没有线程会指向那个buffer。GC会从线程栈开始追踪，并且在任何线程栈中都找不到buffer，因此GC会在稍后某个时间释放内存。所以在一个带GC的编程语言中，你完全不必考虑这个问题。

在C中你可以这样解决这个问题，为对象增加引用计数，引用计数需要被锁或者一些原子性操作保护，当引用计数到达0时，你可以释放内存。

实际中锁加上引用计数代价稍微有点高。如果你想要高性能，并且并发可以扩展到CPU核数，这可能会是个瓶颈，我们在后面介绍RCU的时候会看这部分。所以，如果你想要高性能，好的并发能力，人们倾向于不给读数据加锁。

在实际中，我们会使得读数据至少是不需要锁的，这样你就不需要付出额外的代价。上面是我们在Golang中的实现，我们有个get函数，它会读取并返回链表的头结点。这里就没有使用锁，而是使用了atomic_load，它会读取头结点，但是又不需要锁。后面的pop函数使用了锁。这种风格在Linux内核中非常常见，写数据需要加锁，读数据不用加锁。这里pop函数会从链表中弹出头结点，这样你就可以重用头结点对应的内存。在C中实现这种风格会有点困难，因为有可能当你释放头结点内存时，其他并发的线程正好读取到了头结点的指针。这样当你做完atomic_store，你不能释放指针内容，因为有可能有另一个线程的指针指向了这部分内容。如果你在这里释放了指针内容，你有可能会有use-after-free Bug。

我们在这门课程的最后一节课会看到，Linux内核对这个问题有一种非常聪明的解决办法，被称为Read-Copy-Update或者是RCU。它的工作就是推迟释放内存，直到确定指针不再被使用，并且它有一种非常聪明的方案来决定什么时候可以安全释放内存。但是这个方案有各种各样的限制，程序员需要在RCU关键区域内遵守各种规则。比如说你不能在RCU关键区域sleep，也不能切换线程。

所以尽管实际中Linux内核非常成功的使用了RCU，但是RCU还是有点容易出错，并且需要小心编程来使得它能正确工作。在带有GC的编程语言，例如Golang，这就不是问题了，因为GC会决定某个对象不再被使用，只有这时才释放它。所以现在对于编程人员来说没有限制了，所有的限制都被GC考虑了。这是一种带有GC的编程语言的明显优势。

接下来看看CVEs Bugs，这在前面提到过（注，20.1）。

我们手动的检查了所有的CVEs Bug，并尝试确定Golang是否修复了问题。

• 第一行代表我们不能弄清楚这些Bug的结果是什么，它会怎么展现，我们知道如何修复这些问题，但是我们不能确定Golang是否能避免这些问题。

• 有很多逻辑Bug，可以认为Golang会有与C相同的Bug，所以结果是相同的

• 接下来是40个memory-safety Bugs，包括了use-after-free，double-free，out-of-bound。其中8个直接消失了，因为GC考虑了内存释放，32个会产生panic，比如说数组越界。当然panic并不好，因为内核会崩溃，但是或许要比直接的安全漏洞更好。所以在这40个Bug中，高级编程语言有帮到我们。

以上就是使用高级编程语言实现内核的优势，接下来讨论一些代价，也就是High Level Language Tax。