1. Background
P1: PM(Persistent Memory)介绍，举例Intel-Optane
强调特性：直接通过Memory总线来读写数据，无需软件中间层
强调应用场景：数据库，kvstores
对PM要求：数据能够在发生故障之后仍能恢复
P2: PM编程难点：需要仔细管理读写来保证crash consistency
难点例子：
在presistent链表中添加一个新节点就需要该新节点是尾端指针的persistent prior
难点在编程上带来的变化：
- 为了描述写入顺序(write order），硬件通常会提供writeback和fence 指令，例如CLWB和SFENCE
此外，还有Intel‘s PMDK这种支持failure-atomic transaction的PM libraries - coder必须明白自己调用的指令的crash consistency guarantees，并且需要据此设计failure-recovery mechanism。
该难点带来的bug: - crash consistency bug: 违反了crash consistency guarantee
- 例如: 错误使用了PM原语或者库函数，该用CLWB或者SFENCE的地方没用，没有及时备份数据
- performance bug:
- 在不必要的地方使用了PM crash consistency相关的功能，或者不必要的backups
P3: 目前的工具：
一般方法：跟踪low-level PM operations，检查是否违反了persistence和ordering guarantees
局限：只能检查执行后的trace，不能检查没触发的
例如：
TX_ADD_FIELD() 宏将句柄 o 引用的对象的给定 FIELD 的当前值保存在撤消日志中。 然后应用程序可以*地直接修改指定的 FIELD。 如果发生故障或中止，将恢复保存的值。
https://www.mankier.com/3/pmemobj_tx_add_range
在这个例子中，TX_ADD_FIELD让items[p]可变，但是实际上变的却是items[p-1]，形成crash consistency。
此外，两个函数中各log一次，形成performance bug
此外，作者还认为条件语句if(!parent && node->n< BTREE_MIN)和 if(lsb && lsb->n > BTREE_MIN)都会导致这个trace不一定被触发
本文的方式是优化test case generator
2. Test Case Generation for PM Programs
Proj THUDBFuzz Paper Reading: PMFuzz: Test Case Generation for Persistent Memory Programs