用垃圾收集语言实现垃圾收集器有意义吗
Does it make sense to implement a Garbage Collector in a Language with Garbage Collection
我想在 Java 或 Haskell 中实现垃圾收集器 (GC)，但这有意义吗？
我能否控制我自己的 GC 实现何时启动，而不是实现语言的 GC 启动？
我猜这个问题可以有三种答案：
- 当运行禁用实现语言的GC的虚拟机(VM)时设置标志。
- 使用一种特殊的结构让我管理自己的记忆，比如使用连续传递风格 (CPS) 来管理我自己的评估策略。
- 不，使用没有 GC 的语言。
看看这些：
- 我更喜欢第二个选项，因为我将能够在所有语言中使用该结构。
- 我不喜欢第一个选项，因为我还必须管理解释器的内存。
- （我也不喜欢第三个选项，但我无法控制）
这不是 I build a interpreter on a language with a garbage collector. I need a garbage collector for the interpreter? 的副本，因为我不想 bootstrap 我的解释器与底层 GC。
正如 IT 中经常出现的那样，答案是：这取决于。
当你的解释器控制你的上下文中的所有"objects"；那么当然，您的解释器可能会保留所有 "its" 对象的列表。因此，即使这些对象以某种方式对 JVM 可见，它们也都是可访问的，因此是活动的；所以他们不能受制于 JVM gc。
但是当您以某种方式 "embed" 解释器处理的对象进入周围 java 上下文时 - 那么 JVM gc 可能会负责它们。
从那里开始，答案将转向：是的，这 可能 是可能的。但除此之外；这实际上取决于您的 目标 和驾驶要求。你是为了纯粹的教育目的而实施这个吗？或者您是否有兴趣创造某种对其他人有 "real" 价值的 "real" 产品？
如果是后者，那么您可能希望将您的解释器非常紧密地嵌入到 JVM 中 - 以便从将 JVM 变成今天这个伟大平台的大量投资中获益。你看，近 20 年的研究进入了当前的 JVM JIT 编译器和 GC 技术。你想利用它来 "do your own thing" ...
所以，正如所概述的：这在很大程度上取决于您的 "real" 目标。
最后：您可能会发现 JRuby 上的这个 SE-Radio podcast 和 JVM 平台对您的问题有帮助。 JRuby 的人根本不满意标准 Ruby 引擎的性能；他们选择 JVM 作为构建 更好 Ruby 引擎的平台...
你显然已经对这个问题下定决心了。从某种意义上说，人们提出的 GC 方案可能会比 JVM 已经提供的方案更好。但考虑一下：在所有已被所有杰出开发人员移植到 JVM 的语言中，有多少没有利用 JVM，包括它的 GC？
不过，这是一个意见和实验问题。希望我们都有智慧将一个想法当作假设，并在朝着可能错误的方向旋转之前设法反驳它。如果经得起反驳尝试，那就去做吧
我建议使用您自己设计的相对健壮的示例应用程序实际编程不同的方法。找出 GC 有效性的指标。弄清楚自己编写自己的代码需要付出多少努力，以及它如何影响指标的好坏。然后您自己的经验将指导您。
有什么意义？如果你想实现自己的GC只是为了学习其中涉及的算法，那无所谓。 GC 基本上只是管理相互引用的资源，直到它们不引用为止。这在 Java 和其他 GCed 语言中是完全可行的。您无需释放内存，只需对该对象调用另一个方法并将其从 'living' 个对象的列表中删除即可。
对于运输产品？不确定。您可以利用实现语言中的现有机制，但 GC 尤其需要控制何时应放弃内存。如果实现语言阻止了这一点，那就是个问题。
如果你在Java中编写程序，JVM的GC会自动为你的程序管理内存。你现在想为另一种编程语言实现一个新的 GC，但它也是一个程序。所以JVM的GC会为你自己的GC管理内存，然后你自己的GC会为目标编程语言管理内存。
问题是，如果JVM的GC stop the world，它会停止你自己的GC，你自己的GC也会为你的目标编程语言停止world。
所以，是的，您可以在 Java 或其他语言中使用 GC 实现自己的 GC，但这不是必需的。如果你自己的GC不会被其他GC管理，那也没关系。
我想在 Java 或 Haskell 中实现垃圾收集器 (GC)，但这有意义吗？
我能否控制我自己的 GC 实现何时启动，而不是实现语言的 GC 启动？
我猜这个问题可以有三种答案：
- 当运行禁用实现语言的GC的虚拟机(VM)时设置标志。
- 使用一种特殊的结构让我管理自己的记忆，比如使用连续传递风格 (CPS) 来管理我自己的评估策略。
- 不，使用没有 GC 的语言。
看看这些：
- 我更喜欢第二个选项，因为我将能够在所有语言中使用该结构。
- 我不喜欢第一个选项，因为我还必须管理解释器的内存。
- （我也不喜欢第三个选项，但我无法控制）
这不是 I build a interpreter on a language with a garbage collector. I need a garbage collector for the interpreter? 的副本，因为我不想 bootstrap 我的解释器与底层 GC。
正如 IT 中经常出现的那样，答案是：这取决于。
当你的解释器控制你的上下文中的所有"objects"；那么当然，您的解释器可能会保留所有 "its" 对象的列表。因此，即使这些对象以某种方式对 JVM 可见，它们也都是可访问的，因此是活动的；所以他们不能受制于 JVM gc。
但是当您以某种方式 "embed" 解释器处理的对象进入周围 java 上下文时 - 那么 JVM gc 可能会负责它们。
从那里开始，答案将转向：是的，这 可能 是可能的。但除此之外；这实际上取决于您的 目标 和驾驶要求。你是为了纯粹的教育目的而实施这个吗？或者您是否有兴趣创造某种对其他人有 "real" 价值的 "real" 产品？
如果是后者，那么您可能希望将您的解释器非常紧密地嵌入到 JVM 中 - 以便从将 JVM 变成今天这个伟大平台的大量投资中获益。你看，近 20 年的研究进入了当前的 JVM JIT 编译器和 GC 技术。你想利用它来 "do your own thing" ...
所以，正如所概述的：这在很大程度上取决于您的 "real" 目标。
最后：您可能会发现 JRuby 上的这个 SE-Radio podcast 和 JVM 平台对您的问题有帮助。 JRuby 的人根本不满意标准 Ruby 引擎的性能；他们选择 JVM 作为构建 更好 Ruby 引擎的平台...
你显然已经对这个问题下定决心了。从某种意义上说，人们提出的 GC 方案可能会比 JVM 已经提供的方案更好。但考虑一下：在所有已被所有杰出开发人员移植到 JVM 的语言中，有多少没有利用 JVM，包括它的 GC？
不过，这是一个意见和实验问题。希望我们都有智慧将一个想法当作假设，并在朝着可能错误的方向旋转之前设法反驳它。如果经得起反驳尝试，那就去做吧
我建议使用您自己设计的相对健壮的示例应用程序实际编程不同的方法。找出 GC 有效性的指标。弄清楚自己编写自己的代码需要付出多少努力，以及它如何影响指标的好坏。然后您自己的经验将指导您。
有什么意义？如果你想实现自己的GC只是为了学习其中涉及的算法，那无所谓。 GC 基本上只是管理相互引用的资源，直到它们不引用为止。这在 Java 和其他 GCed 语言中是完全可行的。您无需释放内存，只需对该对象调用另一个方法并将其从 'living' 个对象的列表中删除即可。
对于运输产品？不确定。您可以利用实现语言中的现有机制，但 GC 尤其需要控制何时应放弃内存。如果实现语言阻止了这一点，那就是个问题。
如果你在Java中编写程序，JVM的GC会自动为你的程序管理内存。你现在想为另一种编程语言实现一个新的 GC，但它也是一个程序。所以JVM的GC会为你自己的GC管理内存，然后你自己的GC会为目标编程语言管理内存。
问题是，如果JVM的GC stop the world，它会停止你自己的GC，你自己的GC也会为你的目标编程语言停止world。
所以，是的，您可以在 Java 或其他语言中使用 GC 实现自己的 GC，但这不是必需的。如果你自己的GC不会被其他GC管理，那也没关系。