进行 GC 或不进行 GC

Question

我最近看到了两个非常好的和有教育意义的语言演讲：

这是 Herb Sutter 的第一个，介绍了 C++0x 的所有优秀和酷的功能，为什么 C++ 的未来似乎比以往任何时候都更加光明，以及 M$ 如何被认为是这个游戏中的好人。讨论围绕效率以及如何最大限度地减少堆活动来提高性能。

Andrei Alexandrescu 的另一篇文章激发了从C/C++ 到他的新游戏规则改变者 D。 D 的大部分东西看起来都非常有动机和设计。然而，有一件事让我感到惊讶，即 D 推动垃圾回收，并且所有类都是通过引用单独创建的。更令人困惑的是，The D 编程语言参考手册一书中专门在资源管理部分指出了以下内容，引用：

垃圾收集消除了繁琐且容易出错的工作内存分配跟踪代码 C 和 C++ 中必需的。这不仅意味着更快的开发时间和更低的成本 维护成本，但生成的程序通常运行更快！

这与 Sutter 不断谈论的最小化堆活动相冲突。我非常尊重 Sutter 和 Alexandrescou 的见解，因此我对这两个关键问题感到有点困惑

1. 仅通过引用创建类实例不会导致大量不必要的堆活动吗？

2. 在哪些情况下我们可以在不牺牲性能的情况下使用垃圾收集运行时性能？

Answer 1

直接回答您的两个问题：

1. 是的，通过引用创建类实例确实会导致大量堆活动，但是：

   a.在 D 中，您有 struct 和 class。 struct 具有值语义，并且可以执行类可以执行的所有操作，但多态性除外。

   b.由于切片问题，多态性和值语义从来不能很好地协同工作.

   c.在 D 中，如果您确实需要在某些性能关键型代码中在堆栈上分配类实例并且不关心安全性的损失，则可以通过 scoped 函数。

2. 在以下情况下，GC 可以与手动内存管理相当或更快：

   a.您仍然尽可能在堆栈上进行分配（就像在 D 中通常所做的那样），而不是依赖堆来完成所有操作（就像在其他 GC 语言中经常做的那样）。

   b.你有一个顶级的垃圾收集器（D 当前的 GC 实现确实有些幼稚，尽管它在过去的几个版本中已经看到了一些重大优化，所以它并不像以前那么糟糕）。

   c.您分配的大部分是小对象。如果您分配大部分大型数组并且性能最终成为问题，您可能需要将其中一些切换到 C 堆（您可以访问 C 的 malloc 和 D 中的 free），或者，如果它有作用域生命周期，则可以使用其他一些分配器，例如 RegionAllocator。 （RegionAllocator 目前正在讨论和完善，以便最终包含在 D 的标准库中）。

   d.您不太关心空间效率。如果您让 GC 运行得太频繁以保持内存占用超低，性能将会受到影响。

Answer 2

在堆上创建对象比在堆栈上创建对象慢的原因是内存分配方法需要处理堆碎片等问题。在堆栈上分配内存就像递增堆栈指针一样简单（恒定时间操作）。

然而，使用压缩垃圾收集器，您不必担心堆碎片，堆分配可以与堆栈分配一样快。 D 编程语言的垃圾收集页面更详细地解释了这一点。

GC 语言运行速度更快的断言可能是假设许多程序在堆上分配内存的频率比在堆栈上分配的频率高得多。假设堆分配在 GC 语言中可能更快，那么您刚刚优化了大多数程序的很大一部分（堆分配）。

Answer 3

对 1) 的回答：

只要堆是连续的，在堆上分配就和在堆栈上分配一样便宜。

最重要的是，当您分配彼此相邻的对象时，您的内存缓存性能将会非常好。

只要您不必运行垃圾收集器，就不会损失性能，并且堆保持连续。

这是个好消息:)

回答 2)：

GC 技术已经取得了很大进步；如今，它们甚至具有实时口味。这意味着保证连续内存是一个策略驱动、依赖于实现的问题。

因此，如果

• 您能负担得起实时GC，
• 那么您的应用程序中就有足够的分配暂停，
• 它可以使您的空闲列表保持为空闲块，

您最终可能会获得更好的性能。

回答未提出的问题：

如果开发人员摆脱了内存管理问题，他们可能有更多时间花在代码中的真正性能和可扩展性方面。这也是一个正在发挥作用的非技术因素。

Answer 4

它不是“垃圾收集”或“繁琐且容易出错”的手写代码。真正智能的智能指针可以为您提供堆栈语义，并且意味着您永远不会键入“删除”，但您无需为垃圾收集付费。这是 Herb 的另一个视频，它说明了这一点 - 安全且快速 - 这就是我们想要什么。

Answer 5

另一个需要考虑的点是 80:20 规则。很可能您分配的绝大多数位置都是无关紧要的，即使您可以将那里的成本降低到零，您也不会比 GC 获得太多收益。如果您接受这一点，那么通过使用 GC 获得的简单性可以取代使用它的成本。如果您可以避免复印，则尤其如此。 D 为 80% 的情况提供了 GC，并为 20% 的情况提供了堆栈分配和 malloc 的访问权限。

Answer 6

即使你有理想的垃圾收集器，它仍然会比在堆栈上创建东西慢。因此，您必须拥有一种能够同时支持这两种功能的语言。此外，使用垃圾收集器实现与手动管理的内存分配（以正确的方式完成）相同的性能的唯一方法是使其对内存执行与经验丰富的开发人员所做的相同的操作，并且在许多情况下会这样做要求垃圾收集器在编译时做出决定并在运行时执行。通常，垃圾收集会使事情变得更慢，仅使用动态内存的语言会更慢，并且用这些语言编写的程序的执行可预测性较低，而执行延迟较高。坦率地说，我个人不明白为什么需要垃圾收集器。手动管理内存并不难。至少在 C++ 中不是这样。当然，我不介意编译器生成为我清理所有内容的代码，就像我所做的那样，但这目前似乎不可能。

Answer 7

在许多情况下，编译器可以将堆分配优化回堆栈分配。如果您的对象没有逃脱本地范围，就会出现这种情况。

在下面的示例中，一个像样的编译器几乎肯定会让 x 进行堆栈分配：

void f() {
    Foo* x = new Foo();
    x->doStuff(); // Assuming doStuff doesn't assign 'this' anywhere
    // delete x or assume the GC gets it
}

编译器所做的事情称为 。

此外，D 理论上可以有一个移动 GC，这意味着潜在的性能改进当 GC 将堆对象压缩在一起时，改进了缓存的使用。正如 Jack Edmonds 的回答中所解释的，它还可以对抗堆碎片。类似的事情可以通过手动内存管理来完成，但这是额外的工作。

Answer 8

当高优先级任务未运行时，增量低优先级 GC 将收集垃圾。高优先级线程将运行得更快，因为不会进行内存释放。
这是 Henriksson 的 RT Java GC 的想法，请参阅 http://www.oracle .com/technetwork/articles/javase/index-138577.html

Answer 9

垃圾收集实际上会减慢代码速度。它为除了代码之外还必须运行的程序添加了额外的功能。它还存在其他问题，例如，GC 在实际需要内存时才运行。这可能会导致小的内存泄漏。另一个问题是，如果没有正确删除引用，GC 将不会拾取它，并再次导致泄漏。我对 GC 的另一个问题是它会助长程序员的懒惰。我主张在进入更高级别之前先学习内存管理的低级别概念。这就像数学。您首先学习如何求解二次方的根，或者如何手动求导，然后学习如何在计算器上进行计算。使用这些东西作为工具，而不是拐杖。

如果您不想影响性能，请明智地对待 GC 以及堆与堆栈的使用情况。

Answer 10

我的观点是，当您进行正常的过程编程时，GC 不如 malloc。您只需从一个过程转到另一个过程，分配和释放，使用全局变量，并声明一些函数 _inline 或 _register 。这是C风格。

但是一旦进入更高的抽象层，您至少需要引用计数。因此，您可以通过引用传递，对它们进行计数，并在计数器为零时释放。这很好，并且在对象的数量和层次结构变得难以手动管理之后优于 malloc。这是C++风格。您将定义构造函数和析构函数来递增计数器，您将进行修改时复制，因此一旦一方修改了共享对象的某些部分，但另一方仍然需要原始值，共享对象将一分为二。因此，您可以在函数之间传递大量数据，而无需考虑是否需要在此处复制数据或仅在此处发送指针。引用计数会为您做出这些决定。

然后是全新的世界：闭包、函数式编程、鸭子类型、循环引用、异步执行。代码和数据开始混合，您发现自己比普通数据更频繁地传递函数作为参数。您意识到元编程可以在没有宏或模板的情况下完成。你的代码开始在天空中浸泡并失去坚实的基础，因为你正在回调的回调的回调中执行一些东西，数据变得无根，事情变得异步，你沉迷于闭包变量。因此，这是基于计时器的内存行走 GC 是唯一可能的解决方案，否则闭包和循环引用根本不可能。这是 JavaScript 的方式。

您提到了 D，但 D 仍然是改进的 C++，因此构造函数、堆栈分配、全局变量（即使它们是各种实体的复杂树）中的 malloc 或引用计数可能是您的选择。