garbage-collection - 将 D 用于实时应用程序？

Question

我正在考虑将 d 用于我正在进行的图形引擎。让我失望的一件事是 GC。

我还是一个年轻的程序员，我可能对 GC 有很多误解，我希望你能澄清一些问题。

我的目标是低延迟，一般来说时间是至关重要的。据我所知，GC 是非常不可预测的，例如，我的应用程序可以每 16.6 毫秒渲染一个帧，而 GC 何时启动可能会上升到任何数字，例如 30 毫秒，因为它不是确定性的，对吗？

我读到你可以在 D 中关闭 GC，但是你不能使用 D 的大部分标准库，并且 GC 没有完全关闭。这是真的？

您认为在时序关键应用中使用 D 有意义吗？

Answer 1

简答 :它需要大量定制，如果您不是经验丰富的 D 开发人员，这可能会非常困难。

问题列表 :

内存管理本身并不是什么大问题。在实时应用程序中，您永远不想在主循环中分配内存。为所有主数据预先分配内存池几乎是执行此类应用程序的事实上的标准方法。从这个意义上说，D 并没有什么不同——你仍然直接调用 C malloc 来为你的池获取一些堆，并且这个内存不会由 GC 管理，它甚至不会知道它。

但是，某些语言功能和 Phobos 的大部分内容确实会自动使用 GC。例如，如果没有某种形式的自动管理分配，您就无法真正连接切片。很长一段时间以来，Phobos 都没有对此制定强有力的政策。

很少有语言触发的分配本身不会成为问题，因为大多数使用的内存无论如何都是通过池管理的。但是，库存 D 中的实时软件存在一个致命问题:默认 D 垃圾收集器是 stop-the-world。即使几乎没有垃圾，当收集周期运行时，您的整个程序也会遇到延迟峰值，因为所有线程都会被阻塞。

可以做什么:

1) 使用 GC.disable();关闭收集周期。它将解决 stop-the-world 问题，但现在您的程序将在某些情况下开始泄漏内存，因为基于 GC 的分配仍然有效。

2) 转储隐藏的 GC 分配。有一个针对 -vgc 的拉取请求我现在找不到 switch，但如果没有它，你可以编译自己的druntime 版本，在 gc_malloc() 上打印回溯称呼。您可能希望将其作为自动测试套件的一部分运行。

3) 完全避免火卫一并使用类似 https://bitbucket.org/timosi/minlibd 的东西作为备选。

完成所有这些应该足以满足游戏开发者典型的软实时要求，但正如您所见，这根本不简单，并且需要逐步脱销 D 发行版。

future 替代方案:

一旦 Leandro Lucarella 移植他的 concurrent garbage collector到 D2(计划中，但未计划)，情况会变得简单得多。即使不禁用 GC，少量 GC 管理的内存 + 并发实现也可以满足软实时要求。甚至 Phobos 也可以在从最烦人的分配中剥离后使用。但我认为这不会很快发生。

但是硬实时呢？

你最好不要尝试。但这又是另一个故事了。