为什么引用计数 GC 受到污名化?

发布于 2024-12-28 01:49:41 字数 679 浏览 4 评论 0原文

我曾经在某处读到过一些理想主义但“懒惰”的程序员尝试实现编程语言的共同想法。它如下:-

“我知道,我会做一个易于实现和快速编写的引用计数 GCer,然后当我有时间时将其重新实现为真正的 GCer。”

当然,这种重新实现永远不会发生。

然而,我质疑为什么需要这样的重新实现。为什么增量和并发类型的标记和清除收集器被认为优于 Perl 5 和 Python 等语言所采用的所谓过时的方法? (是的,我知道 Python 通过标记和清除收集器增强了这种方法。)

循环引用是此类讨论中出现的第一个主题。是的,这可能很痛苦(请参阅 Perl 中的递归代码引用,并修复它,涉及多个赋值和引用弱化。)是的,当编码人员必须不断监视此类引用时,它就不那么优雅了。

那么替代方案是否更好呢?我们可以永远讨论细粒度的实现细节,但事实是,大多数标记和清除 GC 实现都存在以下问题: -

  • 资源的非确定性破坏,导致代码难以推理且过于冗长(请参阅 IDispose .NET 中的 try/finally 替换或许多其他语言中的 try/finally 替换。)
  • 不同类别的垃圾(短期、长期以及介于两者之间的所有垃圾)带来额外的复杂性,这种复杂性似乎是合理性能所必需的。
  • 要么需要另一个线程,要么需要定期停止程序的执行来执行收集。

标记和清除的缺点是否有理由解决可以通过弱引用缓解的引用计数问题?

I once read somewhere about a common thought amongst idealistic yet 'lazy' programmers trying their hand at implementing programming languages. It was as follows:-

'I know, I'll do an easy-to-implement and quick-to-write reference counting GCer, and then re-implement it as a real GCer when I get the time.'

Naturally, this reimplementation never occurs.

However, I question why such a reimplementation is needed. Why are mark-and-sweep collectors of the incremental and concurrent variety seen as superior to the allegedly antiquated approach taken by languages like Perl 5 and Python? (Yes, I'm aware Python augments this approach with a mark-and-sweep collector.)

Circular references is the first topic to come up under such discussion. Yes, it can be a pain (see recursive coderefs in Perl, and fix to it involving multiple assignments and reference weakening.) Yes it's not as elegant when a coder has to constantly monitor for references of that ilk.

Is the alternative any better though? We can discuss fine-grained implementation details for eternity, but the fact is, most mark-and-sweep GC implementations have the following problems:-

  • Non deterministic destruction of resources, leading to code that's hard to reason about and too verbose (see IDispose in .NET or the try/finally replacements in many other languages.)
  • Additional complexity with different categories of garbage, for short-lived, long-lived, and everything in-between, with such complexity seemingly required for reasonable performance.
  • Either another thread is required, or the execution of the program needs to be periodically halted to perform the collection.

Are the downfalls of mark-and-sweep justifiable to fix the issues of reference counting which are mitigatable with weak references?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文