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

Question

读取 - 复制 - 更新（RCU）是一种手动内存管理技术，在Linux内核中越来越流行。

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

Answer 1

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

在Linux内核中，当使用RCU时，在schedule()期间进行数据结构以前版本的垃圾收集，因为那时已知所有读者都已完成。

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

---

像JavaScript的Python这样的通用vm 是否可能：很难。

• RCU需要垃圾收集器
• RCU适用于大部分工作负载
• RCU适用于关键的短节

RCU仍然需要垃圾收集器； RCU与垃圾回收器一起使用避免了大多数时间的锁定，也就是说，读取关键部分完成时没有并发写入。

主要是工作负载。引用计数特别繁重，以至于多线程Python VM具有GIL来防止并发的refcount更新，因为这会导致缓存同步损失。因此，需要一些其他技术进行垃圾回收。

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

由于不间断的间接定向，动态语言VM中关键部分的长度特别难以预测。例如，考虑int(code.replace(" ", ""))：int可能通过__int__重载，.replace可能通过属性重载，(...)可能通过{{1}重载}。每个重载都是可能花费很长时间的Python代码。内置数据结构也是如此，其中__call__的更新（最后一条语句）可以在内部使用RCU进行处理，除非必须非常小心，因为c=1; d={c:42}; d[c]=43可能只是实现c花任意时间。

恐怕我对编译语言及其VM的了解还不够。

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

---

虽然这不是一个完整的答案，但我希望这篇扩展的评论有助于界定原始问题。