<分区>
我对设计一种用于音频合成的方案很感兴趣，但我非常关心在满足音频所需的低延迟时进行适当的垃圾收集。我想知道该领域是否有人可以向我指出可能适合这种环境的垃圾收集算法。我正在研究实时垃圾收集，这似乎是有道理的，因为我想限制垃圾收集器所花费的时间，这样我就不会在音频中出现停顿……尽管收集器可能只是“足够快”并很好地分配其工作就足够了吗？我一点都不担心多线程/多处理，我绝对不担心浪费大量空间来寻找这些目标。我追求的是可预测、简单和快速。
谢谢!
<分区>
我对设计一种用于音频合成的方案很感兴趣，但我非常关心在满足音频所需的低延迟时进行适当的垃圾收集。我想知道该领域是否有人可以向我指出可能适合这种环境的垃圾收集算法。我正在研究实时垃圾收集，这似乎是有道理的，因为我想限制垃圾收集器所花费的时间，这样我就不会在音频中出现停顿……尽管收集器可能只是“足够快”并很好地分配其工作就足够了吗？我一点都不担心多线程/多处理，我绝对不担心浪费大量空间来寻找这些目标。我追求的是可预测、简单和快速。
谢谢!
最佳答案
在类 Unix 操作系统的单进程设置中，我听说了一种有趣的方法。 (它是为 Nickle 实验性实现的，但我不知道它是否被合并到 master。)
它使用一个简单的标记-清除收集器，但诀窍在于:当您想要运行标记阶段时，fork()。子进程运行标记，并通过管道将要释放的对象列表发送回父进程，父进程可以在闲暇时逐步释放它们。
这是可行的，因为子进程在父进程内存状态的写时复制快照中运行，由操作系统的内存管理器在硬件 MMU 的帮助下以合理的效率维护。一旦一个对象变得不可访问，它就不会再次被引用，因此从旧快照进行标记总是对可以释放的对象进行保守估计。
编辑:我能找到的关于这项工作的最佳引用是代码之夏提案:http://web.cecs.pdx.edu/~juenglin/revamping.html
关于algorithm - 对停顿最少的垃圾回收算法感兴趣，愿意牺牲空间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13205747/