RCU作为传统垃圾收集的替代品

Question

读取 - 复制 - 更新(RCU)是一种手动内存管理技术,在Linux内核中越来越流行.

是否有可能设计一种使用RCU而不是传统垃圾收集器的语言和VM来回收无法访问的内存？

Answer 1

是否可能：是的，Linux 内核就是一个活生生的例子。

在 Linux 内核中，当使用 RCU 时，会发生前一版本数据结构的垃圾收集schedule()，因为此时已知所有读取器都已完成。

当然，Linux 内核没有垃圾收集器，并且无法访问的内存的回收通常是显式且立即的。RCU更新是一种特殊情况，其中回收是明确的但不是立即的。

像 Python 或 JavaScript 这样的通用虚拟机是否可能：这会很难。

• RCU 需要一个垃圾收集器
• RCU 专为读取为主的工作负载而设计
• RCU 专为短关键部分而设计

RCU仍然需要垃圾收集器；相反，RCU 与垃圾收集器一起工作可以避免大多数情况下的锁定，即当读取关键部分完成但没有并发写入时。

以读取为主的工作负载。引用计数的写入量特别大，以至于多线程 Python VM 有 GIL 来防止并发引用计数更新，因为这会导致缓存同步损失。因此，需要一些其他的垃圾收集技术。

同时，原生 JavaScript 实现根本不需要同步，因为它是单线程的（尽管可以想象 JavaScript 实现将垃圾收集卸载到单独的线程）。

由于不断的间接寻址，动态语言 VM 中临界区的长度特别难以预测。例如，考虑int(code.replace(" ", ""))：int可以通过 重载__int__，.replace可以通过属性重载，(...)可以通过 重载__call__。每个重载都是 Python 代码，可能需要任意长的时间。这同样适用于内置数据结构，其中 update（最后一条语句）可以c=1; d={c:42}; d[c]=43在内部使用 RCU 进行某些操作，但必须非常小心，因为c可能只是实现__hash__可能需要任意长的时间。

恐怕我对编译语言及其虚拟机了解不够。

我的直觉是，新颖的高性能垃圾收集器确实可以在内部使用 RCU，然后可能将 RCU 暴露给内置数据结构的实现。我认为操作系统可能需要提供更好的 API 来将执行固定到特定内核，以便从本地缓存中受益和/或在用户空间被抢占时运行自定义代码。

虽然这不是完整的答案，但我希望这个扩展评论有助于限制最初的问题。