ROART内存安全 内存泄露

ROART 中的memory safety问题

NVM allocators分为两类：

1）logging-based allocator

使用logging确保操作的原子性，引入了额外的持久化开销。

2）post-crash GC

在恢复期间，扫描所有的内存区域来回收垃圾数据。减少了在allocation/deallocation操作时的持久化开销，但是随着数据量的增加从而遭受非常长的恢复时间。

Allocation Performance：（作者测试了五种常用的NVM分配器）

3，4，5，2，1 -->越来越好性能

Garbage Collection

许多索引支持非阻塞的查询（lookup）来提供读的性能。 Lazy GC 机制在这种实施中非常重要。当删除一个item时，在其实际被物理删除之前首先被标记为逻辑删除的，从而避免其它线程的并发访问。在一段（优雅的）时间后，GC线程清扫和搜集逻辑删除的item。

例如，epoch-based GC是lazy GC的常用策略。然而，易失的 Epoch-based GC实现可能会导致NVM中的内存泄漏，因为它不会持久化 被标记的垃圾数据的元数据。 重新启动后，这些垃圾数据将无法访问。

解决此问题的naive方式是为每次元数据修改进行 被标记的垃圾数据的元数据持久化。 作者在支持无锁的查找操作并需要GC机制的FAST&FAIR中比较了epoch-based GC和naive持久化的的epoch-based GC。 如图所示，可以看到基于持久化的epoch-based GC的性能比易失性GC更差25.7％

Post-crash GC在减少了正常操作时的持久化开销。如下图所示，作者测试了使用Makalu和post-crash GC的恢复时间，发现恢复时间随着数据量的增长线性增长。

作者想要设计一个既不导致在naïve epoch-based GC中的持久化开销的GC解决方法们也不遭受post-crash GC中非常长的恢复时间的GC解决方法。

内存管理：

Delayed Check Memory Management

NVM allocation和GC对实际索引有很大的影响。作者提出了一个新的内存管理方法，叫做DCMM，它在allocation/deallocation时使用post-crash GC最小化持久化，并且支持立即重启以消除重启后的等待时间。为了减小多线程之间的内存分配竞争，DCMM使用两层的结构，如图12.

第一层

这一层是全局内存管理器（global memory manager），在页面的粒度下管理整个NVM区域。 页面大小可调节，默认为128MB 。 全局内存管理器维护全局命名空间（global naming space）。 它包含索引的根和指示上次分配页面偏移的偏移字段。 这些是持久化的区域。 还有两个易失性字段，即owner_mapping和Free_page_List。 前者保留在每个页面及其所有者线程之间映射，后者实现了可循环（recycled）的空闲页面的易失性无锁链表（volatile lock-free linked list）。 线程通过搜索free_page_list来请求新页面。 如果free_page_list为空，则它使用原子获取和添加（fetch-and-add）以获取偏移量并以页面大小增加偏移量，然后持久化偏移量。

第二层

对于每个应用程序线程，线程-本地分配器（thread-local allocator）使用具有不同大小的多种块执行分配。 每种块由名为free_chunk_list的易失性链表（volatile linked-list,）维护。 线程从第一层请求页面并将其划分为free_chunk_lists，就像在buddy system中一样。

（什么是buddy system https://blog.csdn.net/liuhangtiant/article/details/81043815）

Garbage Collection.

DCMM 采用post-crash epochbased GC来支持lock-free读和lazy deletions。作者实施了一个decentralized的版本epoch-based GC以获得更好的可扩展性。

Persistence Overhead.

和在§2.3.2节中讨论的一样,基于post-crash GC的分配器不需要再正常操作中持久化任何元数据。因此，持久化开销只发生在第一层，由于持久化偏移量（persisting offset）。 这个开销被第二层的多个内存分配器分担。大多数分配不调用第一层。

Recovery Processing.

恢复后，可以通过以循环方式（round-robin）将范围[0，偏移量]内的每个页面映射到应用程序线程，来简单地重置owner_mapping。 其他易失性信息可以通过三个步骤来恢复（图13）：（i）恢复线程遍历应用程序使用的所有NVM区域（即，从持久化索引的根指针开始并遍历树），并收集所有被使用的带有描述元组（地址，大小）的块（chunk）。 （ii）可以根据每个页面中使用的块来计算空闲块。 （iii）将空闲的块放入free_chunk_lists中，将空闲的页面放入free_page_list中

Instant Restart.

如上所述恢复过程可能随着数据量增加需要很长时间（图5）。 为了减少重新启动后的等待时间，作者提出了立即重启DCMM。 请注意，第一层中的偏移量是被持久化的。 因此，在重新启动后，可以从offset后立即分配新页面，而不用等待其他元数据恢复完成。 （如果偏移量超过当前的NVM文件限制，则将创建一个新的NVM文件，并打开以分配。因此，可以立即允许前端操作并在重新启动后立即提供内存分配服务，且在后台并行运行恢复线程。 通过这种方式，DCMM避免了前端的长时间等待恢复完成。

Multi-threading Optimization.

后台恢复过程可以通过多线程加速。 考虑恢复时的三个步骤。 步骤（i）可以基于数据结构 并行化。 例如，可以使用多个线程来遍历ROART的不同子树。 在遍历期间产生的（address, size）pairs可以基于地址范围放入不同的sorted arrays中。 然后，步骤（ii）和（iii）可以检查不同的sorted arrays并行收集空闲块

Epoch based reclaimation

以数据库领域的Epoch based reclaimation为例，讲一下我的理解。它是一种垃圾回收的算法，基本思想是这样的：每个操作在开始时注册到一个Epoch，可以根据物理时间，每10ms作为一个Epoch操作开始时增加Epoch counter，操作结束时减少Epoch counter操作运行过程中，产生的垃圾都放到epoch内部的garbage list上当这个epoch的所有操作都结束了，即counter等于0时，这个epoch的所有资源都可以释放

用上图举例，这是BwTree的内存垃圾回收。众所周知BwTree是一个latch-free的高性能索引，既然要latch-free那么内存分配一定不能拖后腿了。在对索引进行操作时，例如删除索引的一条数据，并不能直接释放内存，否则无锁算法很容易出现ABA问题。所以在操作过程中产生的垃圾，都放到epoch的garbage list上，当所有线程都退出这个epoch就可以安全地释放掉所有资源。（事实上，上面这个图还是Centralized，Open-BwTree里用了扩展性更好的Decentrailzed实现）Epoch的思想不仅可以应用于内存的回收，它可以认为是引用计数的推广，可以应用于很多其他资源的垃圾回收。

保守GC Conservative garbage collector

保守GC–Conservative GC：“不能识别指针和非指针的GC”
貌似指针的非指针
遇到非指针和堆内的对象的地址一样的情况。这个时候就无法识别这个值是非指针。这就是貌似指针的非指针（fasle pointer）。

保守式GC将这种“貌似指针的非指针”看出指针对象。我们把这种情况叫做“指针的错误识别”。

打个比方，在采用 GC 标记 - 清除算法的情况下，一找到貌似指针的非指针，程序就会将非指针指向的对象错误地识别为活动对象，对其进行标记。因为被错误识别的对象不会被废弃而会被保留，所以遵守了GC的原则—“不废弃活动对象”。像这样，在运行GC时采取的是一种保守的态度，即“把可疑的东西看作指针，稳妥处理”，所以我们称这种方法为“保 守式 GC”。
参考链接：保守GC