为什么Haskell编译器不能促进确定性内存管理？ [英] Why don't Haskell compilers facilitate deterministic memory management?
问题描述
功能性编程语言可以通过跟踪来减少GC用法。虽然一些数据是否可以安全地丢弃是一个普遍的问题，但由于条件分支的原因，这是不可判定的，所以静态工作更加困难，并找到更多的机会来直接释放数据。
值得关注的是Martin Hofmann和移动资源保证项目团队的工作，他们将类型定向内存（de / re）分配作为主题。尽管如此，Haskell在它的类型系统中没有 - 线性。如果您知道函数的输入数据来自其他计算的秘密，则可以重新分配它们占用的内存。 MRG的东西特别好，因为它管理着一种类型的释放和另一种类型的分配之间的实际交换率，这种交换率在纯粹功能性的外观下变成了老式的指针式移动。事实上，使用这些技术可以使很多可爱的简约变异算法（例如指针反转遍历，覆盖尾指针构造等）看起来是纯粹的功能性的（并且检查讨厌的错误）。
实际上，资源的线性分类给出了一种保守但机械可检验的近似使用分析类型，可能有助于减少GC。有趣的问题包括如何将这种治疗干净地（故意的副词选择）与通常的持久性交易混合起来。在我看来，相当多的中间数据结构在递归计算中有一个初始的单线程阶段，在计算完成时被共享或放弃之前。有可能减少这些进程产生的垃圾。
TL; DR有很好的类型化的用法分析方法可以减少GC，但Haskell的错误类型刚才输入的信息对此特别有用。
With the wealth of type information available why can't Haskell runtimes avoid running GC to clean up? It should be possible to figure out all usages and insert appropriate calls to alloc/release in the compiled code, right? This would avoid the overhead of a runtime GC.
It is sensible to ask whether functional programming languages can do less GC by tracking usage. Although the general problem of whether some data can safely be discarded is undecidable (because of conditional branching), it's surely plausible to work harder statically and find more opportunities for direct deallocation.
It's worth paying attention to the work of Martin Hofmann and the team on the Mobile Resource Guarantees project, who made type-directed memory (de/re)allocation a major theme. The thing that makes their stuff work, though, is something Haskell doesn't have in its type system --- linearity. If you know that a function's input data are secret from the rest of the computation, you can reallocate the memory they occupy. The MRG stuff is particularly nice because it manages a realistic exchange rate between deallocation for one type and allocation for another which turns into good old-fashioned pointer-mangling underneath a purely functional exterior. In fact, lots of lovely parsimonious mutation algorithms (e.g. pointer-reversing traversal, overwrite-the-tail-pointer construction, etc) can be made to look purely functional (and checked for nasty bugs) using these techniques.
In effect, the linear typing of resources gives a conservative but mechanically checkable approximation to the kind of usage analysis that might well help to reduce GC. Interesting questions then include how to mix this treatment cleanly (deliberate adverb choice) with the usual persistent deal. It seems to me that quite a lot of intermediate data structures has an initial single-threaded phase in recursive computation, before being either shared or dropped when the computation finishes. It may be possible to reduce the garbage generated by such processes.
TL;DR There are good typed approaches to usage analysis which cut GC, but Haskell has the wrong sort of type information just now to be particularly useful for this purpose.
这篇关于为什么Haskell编译器不能促进确定性内存管理？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
