很长一段时间以来，我一直将 LLVM 作为我目前正在实施的语言的新后端。它似乎具有良好的性能，相当高级的生成 API，足够的低级支持来优化外来优化。此外，虽然我自己没有检查过，但 Apple 似乎已经成功地展示了 LLVM 用于垃圾收集的多核程序。
到目前为止，一切都很好。由于我对垃圾收集和多核都感兴趣，下一步将是选择一个 LLVM 多核垃圾收集器。这让我想到了一个问题：什么是可用的？我知道Jon Harrop的 HLVM 工作，但仅此而已。
请注意，我需要跨平台，因此 Apple 的 GC 可能不是我想要的（除非有跨平台版本）。另请注意，我不反对停止世界垃圾收集器。
在此先感谢，约里克
如矩阵所示，LLVM 的垃圾收集基础设施已经适用于各种收集器，但目前还没有扩展到多线程程序。这将在将来添加，因为有兴趣。
文档确实说要进行多线程垃圾收集，您需要停止世界，这是一件不可移植的事情：
Threaded 表示一个多线程的mutator；在开始可达性分析之前，收集器仍然必须停止 mutator（“停止世界”）。停止多线程 mutator 是一个复杂的问题。它通常在运行时需要高度特定于平台的代码，并在安全点生成精心设计的机器代码。
但是，线程之间的共享状态是一个令人讨厌的扩展问题。如果您的语言仅通过“任务”之间的消息传递进行通信，因此工作线程之间没有共享状态，那么您可以为每线程堆使用每线程收集器吗？
Will 给出的引述是关于 LLVM 对 GC 的内在支持，您可以在其中使用 C++ 代码来增强 LLVM，告诉它如何遍历堆栈、解释堆栈帧、注入读写屏障等等。我的HLVM项目的主要目标是以最小的努力和风险变得有用，因此我选择将影子堆栈用于“不合作的环境”，以避免对 LLVM 不成熟的内部结构进行黑客攻击。因此，关于 LLVM 对 GC 的内在支持的那些声明不适用于HLVM的垃圾收集器，因为它根本不使用该基础设施。我的结果非常引人注目：您可以用最少的努力实现出色的性能（串行性能和并行性能）。
我相信HLVM已经在包括 Mac OS X 在内的 Unix 上开箱即用，因为它只需要 POSIX 线程。我强烈不同意编写一个 stop-the-world GC 很困难的说法：我花了 5 天时间编写了一个 100 行的多核垃圾收集器，而我对计算机几乎一无所知。我不敢相信移植到 Windows 也很困难。