Mai*_*ein 4 garbage-collection d
我正在考虑将d用于我正在进行的图形引擎.让我失望的一件事是GC.
我还是一个年轻的程序员,我可能对GC有很多误解,我希望你能澄清一些问题.
我的目标是低延迟,一般来说时序至关重要.据我所知,GC是非常不可预测的,例如我的应用程序可以每16.6ms渲染一帧,到GC的时候它可以上升到任何数字,如30ms,因为它不确定吗？
我读过你可以在D中调低GC,但是你不能使用D的大部分标准库而且GC没有完全关闭.这是真的？
您是否认为在关键时序应用中使用D是有意义的？
简短的回答:它需要大量的定制,如果你不是一个经验丰富的D开发人员,那真的很难.
问题清单:
内存管理本身并不是一个大问题.在实时应用程序中,您永远不想在主循环中分配内存.为所有主数据预先分配内存池实际上是执行此类应用程序的标准方法.在这个意义上,D没有什么不同 - 你仍然直接调用C malloc为你的池获取一些堆,这个内存不会由GC管理,它甚至都不知道它.
但是,Phobos的某些语言功能和大部分功能会自动使用GC.例如,如果没有某种形式的自动管理分配,您无法真正连接切片.Phobos在很长一段时间内根本就没有强有力的政策.
很少有语言触发的分配本身不会成为问题,因为大多数使用的内存无论如何都是通过池来管理的.然而,库存D中的实时软件存在一个杀手级问题:默认D垃圾收集器是世界末日.即使几乎没有垃圾,当收集周期运行时,整个程序也会遇到延迟峰值,因为所有线程都会被阻塞.
可以做些什么:
1)用于GC.disable();关闭收集周期.它将解决世界问题,但现在你的程序将在某些情况下开始泄漏内存,因为基于GC的分配仍然有效.
2)转储隐藏的GC分配.有一个拉动请求-vgc切换,我现在找不到,但在它缺席的情况下你可以编译自己的druntime版本,在gc_malloc()打电话时打印回溯.您可能希望将其作为自动测试套件的一部分运行.
3)完全避免使用Phobos,并使用https://bitbucket.org/timosi/minlibd等替代方法.
完成所有这些操作应足以满足游戏开发者典型的软实时要求,但正如您所看到的那样,它并不简单,需要逐步淘汰库存D分发.
未来的选择:
一旦Leandro Lucarella将他的并发垃圾收集器移植到D2(计划但未安排),情况将变得更加简单.即使不禁用GC,少量GC管理的内存+并发实现也可以满足软实时要求.甚至Phobos也可以在从最烦人的分配中剥离后使用.但我不认为它会很快发生.
但是硬实时呢？
你最好不要尝试.但这是另一个要讲述的故事.