垃圾回收如何以本地编译的语言工作？

浏览了堆栈溢出的几个答案之后，很明显，一些本机编译的语言具有垃圾回收功能。但是我不清楚这将如何工作。

我了解垃圾收集如何与解释语言一起工作。垃圾收集器将仅与解释器一起运行，并从程序的内存中删除未使用和无法访问的对象。他们俩一起跑。

但是，如何使用编译语言呢？我的理解是，一旦编译器将源代码编译为目标代码（特别是本机代码），就完成了。它的工作完成了。那么，编译后的程序又如何被垃圾回收呢？

在执行程序删除“垃圾”对象时，编译器是否以某种方式与CPU一起工作？还是编译器在编译程序的可执行文件中包括一些最小的垃圾回收器。

我相信我的后一种说法将比前一种更具有效性，这是由于从Stack Overflow的答案中摘录的：

一种这样的编程语言是埃菲尔。大多数Eiffel编译器出于可移植性原因而生成C代码。该C代码用于通过标准C编译器生成机器代码。埃菲尔实现为该已编译的代码提供GC（有时甚至是精确的GC），并且不需要VM。特别是，VisualEiffel编译器直接在完全GC支持下生成了本机x86机器代码。

最后一条语句似乎暗示编译器在最终的可执行文件中包含一些程序，该程序在运行时充当垃圾回收器。

在页面d语言的关于垃圾收集的网站这是本地编译并具有可选的垃圾收集器- -似乎也暗示了一些后台程序运行沿着原来的可执行程序来实现垃圾回收。

D是一种支持垃圾回收的系统编程语言。通常，没有必要显式释放内存。只需根据需要进行分配，垃圾收集器就会定期将所有未使用的内存返回到可用内存池。

如果方法上面提到的被使用，究竟会工作的呢？编译器是否存储一些垃圾回收程序的副本并将其粘贴到它生成的每个可执行文件中？

还是我的思维有缺陷？如果是这样，使用什么方法来实现编译语言的垃圾回收，它们将如何工作？

编译语言中的垃圾回收与解释语言中的垃圾回收相同。像Go这样的语言使用跟踪垃圾收集器，即使它们的代码通常会提前被编译为机器代码。

（跟踪）垃圾收集通常从遍历当前正在运行的所有线程的调用堆栈开始。这些堆栈上的对象始终是活动的。此后，垃圾收集器遍历活动对象指向的所有对象，直到发现整个活动对象图。

显然，这样做需要C等语言不提供的额外信息。特别是，它需要每个函数的堆栈框架的映射，其中包含所有指针的偏移量（可能还有它们的数据类型），以及包含相同信息的所有对象布局的映射。

但是，很容易看出具有强类型保证的语言（例如，如果不允许将指针强制转换为不同的数据类型）确实可以在编译时计算这些映射。它们只是将指令地址与堆栈框架映射之间的关联以及数据类型与对象布局映射之间的关联存储在二进制文件内。然后，此信息使他们可以进行对象图遍历。

垃圾收集器本身不过是一个链接到程序的库，类似于C标准库。例如，malloc()如果内存压力很高，该库可以提供类似于运行收集算法的功能。

编译器是否存储某些垃圾回收程序的副本并将其粘贴到其生成的每个可执行文件中？

听起来很古怪而奇怪，但是是的。编译器具有一个完整的实用程序库，其中不仅包含垃圾回收代码，还包含许多其他内容，对该库的调用将插入到其创建的每个可执行文件中。这称为运行时库，您会惊讶于它通常执行多少个不同的任务。

还是编译器在编译后的程序代码中包括一些最小的垃圾回收器。

这是一种奇怪的说法，“编译器将程序与执行垃圾回收的库链接在一起”。但是，是的，就是这样。

这没什么特别的：编译器通常将大量的库链接到它们所编译的程序中。否则，如果不从头开始重新实现许多事情，已编译的程序将无法完成很多工作：即使将文本写入屏幕/文件/…也需要一个库。

但是也许GC与这些其他库不同，其他库提供用户调用的显式API？

否：在大多数语言中，除了GC之外，运行时库在没有面向公众的API的情况下也会执行许多幕后工作。考虑以下三个示例：

1. 异常传播和堆栈展开/析构函数调用。
2. 动态内存分配（即使没有垃圾回收，通常也不只是像C中那样调用函数）。
3. 跟踪动态类型信息（用于强制转换等）。

因此，垃圾收集库一点都不特殊，先验与程序是否提前编译无关。

但是，如何使用编译语言呢？

你的措辞是错误的。一个编程语言是一种规范编写一些技术报告（对于一个很好的例子，见R5RS）。实际上，您指的是某些特定的语言实现（这是一种软件）。

^{（某些编程语言的规范不正确，甚至缺少规范，或者仅与某些示例实现相符；尽管如此，编程语言还是定义了一种行为 -例如，它具有语法和语义 -它不是软件产品，但可能是实现由一些软件产品，很多编程语言有几种实现方式;特别是，“编译”是一个形容词适用于实现 -即使有些编程语言更容易口译不是由编译器实现）。}

我的理解是，一旦编译器将源代码编译为目标代码（特别是本机代码），就完成了。它的工作完成了。

注意，解释器和编译器的含义很松散，某些语言实现可能被视为两者兼而有之。换句话说，两者之间是连续的。阅读最新的《Dragon Book》，并考虑字节码，JIT编译，动态地发出被编译为某个“插件”的C代码，然后由同一进程dlopen（3）编辑（在当前机器上，此速度足够快以与交互式REPL，请参阅此）

我强烈建议您阅读GC手册。需要一本书来回答。在此之前，请阅读垃圾收集维基页面（我假设您已阅读以下内容）。

编译语言实现的运行时系统包含垃圾回收器，并且编译器正在生成适合该特定运行时系统的代码。特别是，分配原语（被编译为机器代码）将（或可能）调用运行时系统。

那么，编译后的程序又如何被垃圾回收呢？

仅通过发出使用（且“友好”且“兼容”）运行时系统的机器代码即可。

请注意，您可以找到几个垃圾收集库，特别是Boehm GC，Ravenbrook的MPS甚至是我的（未维护的）Qish。而且，编写简单的 GC并不是很困难（但是，调试起来更困难，而编写具有竞争力的 GC则很困难）。

在某些情况下，编译器将使用保守的 GC（例如Boehm GC）。这样，就没有太多要编写的代码了。保守的GC有时会（当编译器调用其分配例程时，或整个GC例程时）扫描整个调用堆栈，并假定从调用堆栈可以（间接）访问的任何内存区域均处于活动状态。之所以称为保守 GC，是因为丢失了键入信息：如果调用堆栈上的整数恰好看起来像某个地址，则会跟随它，依此类推。

在其他（更困难的）情况下，运行时提供了分代复制垃圾收集（典型示例是Ocaml编译器，该编译器使用此类GC将Ocaml代码编译为机器代码）。然后的问题是精确地在调用堆栈中找到所有指针，其中一些指针由GC 移动。然后，编译器生成描述运行时使用的调用堆栈帧的元数据。因此，调用约定和ABI变得特定于该实现（即编译器）和运行时系统。

在某些情况下，由编译器生成的机器代码（实际上甚至指向它的闭包）本身都是垃圾收集的。SBCL（一种很好的Common Lisp实现）尤其如此，它为每个REPL交互生成机器代码。这也需要一些元数据来描述代码及其内部使用的调用框架。

编译器是否存储一些垃圾回收程序的副本并将其粘贴到它生成的每个可执行文件中？

有点。不过，运行时系统可以是共享库，等等。有时（在Linux和其他几个POSIX系统），它甚至可以是一个脚本解释器，例如传递到（2）的execve用家当。或ELF解释器，请参见elf（5）和PT_INTERP，等等。

顺便说一句，当今大多数带有垃圾回收语言的编译器（及其运行时系统）都是免费软件。因此，请下载源代码并进行研究。

已经有了一些好的答案，但是我想清除这个问题背后的一些误解。

本身没有“本地编译语言”这样的东西。例如，相同的Java代码在我的旧手机（Java Dalvik）上进行了解释（然后在运行时进行了部分即时编译），并在（我的）新手机（ART）上进行了（提前）编译。

本机运行代码和解释运行代码之间的区别远没有看起来那么严格。两者都需要一些运行时库和某些操作系统才能运行（*）。解释后的代码需要一个解释器，但是解释器只是运行时的一部分。但这还不严格，因为您可以用（即时）编译器替换解释器。为了获得最佳性能，您可能需要两者（桌面Java运行时包含一个解释器和两个编译器）。

无论如何运行代码，其行为都应相同。分配和释放内存是运行时的任务（就像打开文件，启动线程等一样）。用您的语言，您只是写作new X()或类似。语言规范说明应该发生什么，然后运行时执行。

分配了一些可用内存，调用了构造函数，等等。如果没有足够的内存，则会调用垃圾收集器。因为您已经在运行时（运行时是本机代码），所以解释器的存在根本无关紧要。

在代码解释和垃圾回收之间确实没有直接的联系。仅仅是像C这样的低级语言是为速度和对所有内容的细粒度控制而设计的，这与非本机代码或垃圾收集器的思想不太吻合。因此，只有一种相关性。

在过去，这是非常正确的，例如，Java解释器很慢，而垃圾收集器的效率很低。如今，事情已经大不相同了，谈论解释性语言已经失去了任何意义。

（*）至少在谈论通用代码时，不要使用引导加载程序和类似内容。

各个实现之间的细节有所不同，但通常是以下各项的组合：

• 包含GC的运行时库。这将处理内存分配并具有其他一些入口点，包括“ GC_now”函数。
• 编译器将为GC创建表，以便它知道引用哪些数据类型的字段。对于每个功能的堆栈框架也将执行此操作，以便GC可以从堆栈进行跟踪。
• 如果GC是增量的（GC活动与程序交错）或并发的（在单独的线程中运行），则编译器还将包含特殊的目标代码，以在更新引用时更新GC数据结构。两者在数据一致性方面存在类似的问题。

在增量式和并发GC中，编译后的代码和GC需要配合以维护某些不变性。例如，在复制收集器中，GC的工作原理是将活动数据从空间A复制到空间B，而留下垃圾。对于下一个循环，它将翻转A和B并重复。因此，一条规则可以是确保用户程序在任何时候尝试引用空间A中的对象时，都会检测到该对象，并将该对象立即复制到空间B中，程序可以在该空间继续访问它。转发地址留在空间A中，以向GC指示已发生这种情况，以便在跟踪对象时对对象的任何其他引用进行更新。这被称为“读取屏障”。

从60年代开始就对GC算法进行了研究，并且有大量有关该主题的文献。Google如果您需要更多信息。