我正在研究将执行程序的状态存储到磁盘并再次将其带回的基本原则。在我们目前的设计中，每个对象（这是一个带有函数指针列表的 C 级事物，一种低级的自制面向对象——这样做有很好的理由）将是调用以将其显式状态导出为可写和可恢复的格式。使这项工作的关键属性是与对象相关的所有状态确实封装在对象数据结构中。
还有其他使用活动对象的解决方案，其中有一个用户级线程附加到某些对象。因此，程序计数器、寄存器内容和堆栈内容突然成为程序状态的一部分。据我所知，没有好的方法可以在任意时间点将这些东西序列化到磁盘上。线程必须将自己停放在程序计数器等不表示任何内容的特殊状态下，因此基本上将它们的执行状态机状态“保存”到显式对象状态。
我查看了一系列序列化库，据我所知，这是一个通用属性。
核心问题是：或者事实并非如此？就线程在其代码中执行的位置而言，是否有可以包括线程状态的保存/恢复解决方案？
请注意，在虚拟机中保存整个系统状态不算数，这并不是真正序列化状态，而只是冻结机器并移动它。这是一个明显的解决方案，但大多数时候有点重量级。
有些问题清楚地表明，我在解释我们如何做事的想法时不够清楚。我们正在开发一个模拟器系统，对于在其中运行的代码有非常严格的规则是允许编写的。特别是，我们完全区分了对象构造和对象状态。每次设置系统时都会重新创建接口函数指针，而不是状态的一部分。状态仅由特定指定的“属性”组成，每个“属性”都具有定义的获取/设置函数，该函数在内部运行时表示和存储表示之间进行转换。对于对象之间的指针，它们都被转换为名称。所以在我们的设计中，一个对象可能会像这样在存储中出现：
Object foo {
value1: 0xff00ff00;
value2: 0x00ffeedd;
next_guy_in_chain: bar;
}
Object bar {
next_guy_in_chain: null;
}
链表从未真正存在于模拟结构中，每个对象代表某种硬件单元。
问题是有些人想这样做，但也有线程作为编码行为的一种方式。这里的“行为”实际上是模拟单元状态的突变。基本上，我们的设计说所有这些更改都必须在原子完整操作中进行，这些操作被调用、完成它们的工作并返回。所有状态都存储在对象中。你有一个反应模型，或者它可以被称为“运行到完成”或“事件驱动”。
另一种思考方式是让对象有活动的线程在它们上面工作，它们像经典的 Unix 线程一样处于一个永恒的循环中，并且永远不会终止。这是我试图查看它是否可以合理地存储到磁盘的情况，但是如果不在下面插入 VM，这似乎是不可行的。
2009 年 10 月更新：与此相关的论文发表在 2009 年的 FDL 会议上，请参阅这篇关于检查点和 SystemC 的论文。