Liveness-Based Garbage Collection for Lazy Languages
我们考虑的问题，减少运行懒惰的一阶函数程序所需的内存。我们的方法是分析程序的堆分配数据的活性。分析结果用于在垃圾回收期间仅保留活动数据--可访问数据的子集。结果是回收的垃圾增加，程序的峰值内存需求减少。虽然这种技术已经被证明可以为渴望一阶语言带来好处，但缺乏可静态确定的执行顺序和闭包的存在对懒惰语言提出了新的挑战。这些都需要在活性分析本身和垃圾收集器的设计中进行更改。为了显示我们的方法的有效性，我们实现了一个复制收集器，它使用活性分析的结果来保存活对象，两者都被评估（即，在WHNF中）和关闭。我们的实验证实，对于使用基于活动的垃圾收集器运行的程序，峰值内存需求显著降低。此外，收集数量的大幅减少确保了尽管使用了更复杂的垃圾收集器，但使用活跃度和基于可达性的收集器运行的程序的执行时间仍然相当。
2016-05-02 cs.PL
Understanding Lua's Garbage Collection -- Towards a Formalized Static Analyzer
我们为Lua程序设计语言提供了垃圾回收（GC）的语义。有趣的是包含了终结器（类似于面向对象语言中的析构函数）和弱表（弱引用的一种特殊实现）。该模型表达了与GC相关的几个方面，这些方面在Lua的文档中没有涉及，但却影响了程序的可观察行为。我们的模型是机械化的，可以用真实的程序进行测试。我们的长期目标是提供一个正式的Lua程序静态分析器来检测潜在的危险。作为第一步，我们提供了一个原型工具LuaSafe，它可以对程序进行类型转换，以确保它们的行为不受GC的影响。我们的GC模型在实践中通过实验与其机械化进行了验证，并在理论上证明了几个健全的性质。
2020-05-26 cs.PL
Practical Aspects for a Working Compile Time Garbage Collection System for Mercury
编译时垃圾回收（CTGC）在编译器中仍然是一个非常少见的特性。在以前的工作中，我们已经开发了一个编译时结构重用系统的水星，逻辑程序设计语言。该系统指出哪些数据结构可以在运行时安全地重用。由于初步实验是有希望的，我们继续这项工作，现在有一个工作和良好的性能近船CTGC系统内置到墨尔本汞回收器（MMC）。在本文中，我们提出了多个设计决策，导致这个系统，我们报告的结果，使用CTGC的一组基准，包括一个现实世界的程序，最后，我们讨论进一步可能的改进。基准测试显示大量的内存节省和执行时间的显着减少。
2001-10-17 cs.PL
Garbage Collection in JyNI - How to bridge Mark/Sweep and Reference Counting GC
Jython是一个基于Java的Python实现，是集成Python和Java的最无缝的方式。它通过将Python代码编译为Java字节码并让Java的JIT对其进行优化来实现高效率-这种方法使Python代码能够调用Java函数或子类化Java类。它使Python代码能够利用Java的多线程特性，并利用Java内置的垃圾回收（GC）。但是，它目前不支持CPython的C-API，因此不支持NumPy和SciPy等原生扩展。由于大多数科学代码都依赖于这样的扩展，所以它不能在Jython中运行。Jython Native Interface（JyNI）是一个兼容层，旨在在Jython之上提供CPython的原生C扩展API。JyNI是使用Java本机接口（JNI）实现的，它的本机部分被设计为与现有扩展构建二进制兼容。
2016-07-01 cs.PL
Effectiveness of Garbage Collection in MIT/GNU Scheme
Scheme使用垃圾回收进行堆存储管理。理想情况下，垃圾收集器应该能够回收所有死对象，即将来不会使用的对象。但是，垃圾收集器只收集那些无法从任何程序变量访问的死对象。可从程序变量访问的死对象不会被回收。在本文中，我们描述了我们的实验来衡量垃圾回收的有效性，在MIT/GNU计划。我们计算对象的拖动时间，即对象在最后一次使用后在堆内存中保留的时间。死亡对象的数量和拖动时间共同表明了改进垃圾回收的机会。我们的实验表明，多达26%的死亡对象仍然存在于内存中。平均拖动时间高达执行时间的37%。总体而言，我们观察到内存节省潜力从9%到65%不等。
2007-09-01 cs.PF cs.PL
Prioritized Garbage Collection: Explicit GC Support for Software Caches
程序员经常用空间换取时间来提高性能，通常是以缓存或备忘录的形式。然而，在Java或JavaScript等托管语言中，这种空间-时间权衡是复杂的。使用更多的空间意味着更高的垃圾回收成本，特别是在可用内存有限的情况下。现有的运行时系统对空间敏感的算法提供了有限的支持，迫使程序员在配置方面做出困难且往往脆弱的选择。本文提出了优先级的垃圾回收，一个合作的程序设计语言和运行时解决这个问题。优先级GC提供了一个类似于软引用的接口，称为优先级引用，它标识收集器可以在必要时急切地回收的对象。关键的区别在于定义策略的API，该策略控制何时清除优先级引用以及清除的顺序。应用程序代码为每个引用指定一个优先级值和一个目标内存界限。收集器回收引用，优先级最低的引用优先，直到缓存的总内存占用量符合限制。我们使用这个API来实现一个空间感知的最近最少使用（LRU）缓存，称为Sache，它是现有缓存（如Google的Guava库）的直接替代品。垃圾收集器会根据可用的内存和工作负载自动增长和收缩Sache，而程序员只需要提供最少的配置信息。使用Sache，应用程序几乎不可能遇到由软件缓存引起的内存泄漏、内存压力或内存不足崩溃。
2016-10-15 cs.PL
Garbage Collection for Multicore NUMA Machines
现代高端机器具有多个处理器包，每个处理器包都包含多个独立的内核和直接连接到专用物理RAM的集成内存控制器。这些封装通过共享总线连接，从而创建具有异构存储层次结构的系统。由于该共享总线的带宽小于到内存的链路的总和，因此当并行线程都访问其处理器包的本地内存时，总内存带宽高于它们访问附加到远程包的内存时。这种带宽限制传统上限制了现代函数式语言实现的可扩展性，即使在小型基准测试中，也很少能扩展到8个核心以上。这项工作提出了一个垃圾收集器与我们严格的，并行的函数式语言实现，Manticore集成，并表明它可以有效地扩展到48核AMD皓龙机器和32核英特尔至强机器。
2011-05-12 cs.PL
Garbage Collection for Rust: The Finalizer Frontier
本文提出 Rust GC 框架 Alloy，使现有析构函数可自动作为 GC finalizer，并通过安全分析、省略优化与过早运行防护解决健全性和性能问题。
2025-09-30 cs.PL
Virtual Garbage Collector (VGC): A Zone-Based Garbage Collection Architecture for Python's Parallel Runtime
VGC通过基于区域的内存管理和分区执行，提高Python运行时的可预测性和可扩展性。
2026-01-01 cs.DC cs.PL
Stack-Summarizing Control-Flow Analysis of Higher-Order Programs
高阶流分析中有两个汇会消耗精度：（1）在过程调用时合并参数值，以及（2）在过程返回时合并返回值。为了防止精度损失，这两个汇已被独立处理。在过程调用的情况下，抽象垃圾回收减少了参数合并;而在过程返回的情况下，上下文无关方法消除了返回值合并。很自然地，人们期望综合分析可以享受这两种方法之间的互利互动。这项工作的核心贡献是抽象的垃圾回收与上下文无关的分析的直接产品。要克服的主要挑战是下推系统的核心约束和垃圾回收的需求之间的冲突：下推系统只能看到堆栈的顶部，而垃圾回收需要在收集期间看到整个堆栈。为了使直接产品可计算，我们开发了“堆栈摘要”，在每个控制状态下推分析高阶程序跟踪堆栈属性的方法。
2010-09-08 cs.PL
Introspective Pushdown Analysis of Higher-Order Programs
在函数式程序的静态分析中，下推流分析和抽象垃圾回收恰好在可靠性和可判定性的边界内。单独使用，每种方法都可以减少分析时间，并将精度提高几个数量级。这项工作阐明并克服了理论上的挑战，这些挑战阻碍了将这些技术的力量结合起来。结合这些技术的挑战并不微妙：计算下推系统的可达控制状态依赖于在转换到堆栈顶部期间限制访问;另一方面，抽象垃圾回收需要完全访问整个堆栈来计算根集，就像具体收集一样。\emph{Introspective}下推系统可解决此冲突。内省下推系统提供了对堆栈的足够访问，以允许抽象垃圾回收，但它们仍然受到足够的限制，以计算控制状态的可达性，从而实现下推分析和抽象垃圾回收的可靠和精确的产品。实验揭示了这些技术之间的协同作用，融合展示了“优于两个世界”的精度。
2012-07-07 cs.PL
Low-Latency, High-Throughput Garbage Collection (Extended Version)
生产垃圾收集器在追求减少暂停时间方面做出了实质性的妥协。它们需要比以前更简单的收集器多得多的CPU周期和内存。并发复制收集器（C4、ZGC和Shenandoah）受到以下设计限制。1)同时复制。它们仅通过复制来回收内存，这本身就很昂贵，并且内存带宽要求很高。并发复制还需要昂贵的读写屏障。2)可扩展性。它们依赖于追踪，而追踪在极限和实践中是不成比例的。3)即时性。它们不会立即回收较旧的对象，从而导致较高的内存开销。我们提出了LXR，它采用了一种非常不同的方法，通过最大限度地减少并发收集工作和开销来优化响应能力和吞吐量。1)LXR通过使用Immix堆结构回收大部分内存而不进行任何复制。然后，它通过有限的明智的停止世界复制来对抗碎片化。2)LXR使用引用计数来实现可伸缩性和即时性，及时回收年轻和旧对象。它根据需要使用并发跟踪来识别循环垃圾。3)为了最小化暂停时间，同时允许明智地复制成熟对象，LXR引入了用于引用计数和并发递减处理的记忆集。4)LXR引入了一种新颖的低开销写屏障，它结合了合并引用计数、并发跟踪和记忆集维护。其结果是收集器具有出色的响应性和吞吐量。在广泛使用的Lucene搜索引擎上，LXR具有6倍的吞吐量，同时提供比流行的Shenandoah生产收集器低30倍的99.9%尾部延迟。
2022-10-31 cs.PL
Garbage Collection Makes Rust Easier to Use: A Randomized Controlled Trial of the Bronze Garbage Collector
Rust是一种通用程序设计语言，它是类型安全和内存安全的。Rust不使用垃圾收集器，而是通过一个复杂但复杂的类型系统来实现这些属性。这样做使Rust非常高效，但使Rust相对难以学习和使用。我们为Rust设计了Bronze，一个可选的、基于库的垃圾收集器。为了看看Bronze是否能让Rust更有用，我们对来自633人班级的志愿者进行了一项随机对照试验，总共收集了428名学生的数据。我们发现，对于需要管理复杂别名的任务，青铜级用户更有可能在可用时间内完成任务，而那些这样做的人只需要大约三分之一的时间（4小时对12小时）。我们发现总时间没有显著差异，即使青铜用户在没有青铜之后重新完成任务。调查表明，所有权、借用和生命周期是用户在使用Rust时面临挑战的主要原因。
2022-02-15 cs.PL cs.SE
Garbage Collection or Serialization? Between a Rock and a Hard Place!
大数据分析框架，如Spark和Giant，需要处理和缓存大量数据，这些数据并不总是适合堆。因此，框架暂时将长期对象移动到托管堆之外（堆外）的快速存储设备上。不幸的是，这种做法会导致：（1）高序列化/非序列化（S/D）成本，以及（2）当堆外对象移回托管堆进行处理时，内存压力很大。在本文中，我们提出了TeraHeap，这是一个消除大数据框架中大部分对象的S/D开销和昂贵的GC扫描的系统。TeraHeap依赖于三个概念。(1)它通过扩展托管运行时（JVM）以在快速存储设备上使用第二个高容量堆（H2）来消除S/D成本。(2)它通过屏蔽垃圾收集器扫描H2对象来降低GC成本。(3)它提供了一个简单的基于提示的接口，允许框架利用关于对象的知识来填充H2。我们在OpenJDK中实现了TeraHeap，并在两个真实世界的大数据框架Spark和Giant中使用15个广泛使用的应用程序对其进行了评估。我们的评估表明，对于相同的DRAM大小，TeraHeap与原生Spark和GitHub相比，性能分别提高了73%和28%。此外，它提供了更好的性能，消耗高达8倍和1.2倍的DRAM容量分别比原生Spark和Giant。最后，它比Panthera（一种混合存储器的垃圾收集器）的性能高出69%。
2023-01-09 cs.PL
Exploiting array manipulation habits to optimize garbage collection and type flow analysis
本文利用数组操作习惯，通过向垃圾回收器传递供应区域信息以避免标记，并分析数组对象类型，优化垃圾回收与类型流分析，提升编译器性能。
2023-10-16 cs.PL
A Novel Design of a Parallel Machine Learnt Generational Garbage Collector
Anna University（安娜大学）
分代垃圾回收涉及将堆组织成不同的内存空间分区，以便通过将每个代垃圾回收周期的存活对象移动到另一个内存空间，更新其年龄并从死亡对象中回收空间，从而从短期对象中过滤长期对象。这种方法的问题是，对象在其初始生成期间存活的时间越长，垃圾收集器将不得不通过从根检查其可达性并将其提升到其他空间分区来处理它，而垃圾收集器的最终目标是在尽可能短的时间内从不可达对象中回收内存。本文提出了一种方法，即预测每个进入堆的对象的生存期，并将其相应地放置在堆中，以便垃圾收集器更多地处理从死对象中回收空间的问题，而较少地将活对象提升到更高的级别。
2015-01-06 cs.AI cs.PL
Scheduling Garbage Collection for Energy Efficiency on Asymmetric Multicore Processors
本文研究单-ISA AMP 上 Java ZGC 的核调度，发现将 GC 放到 e-cores 可在不损害性能与延迟的前提下节能约3%，调核数后最高达5.3±0.0225%。
2024-03-04 cs.PL
Optimal Heap Limits for Reducing Browser Memory Use
垃圾收集语言运行时会仔细调优堆限制，以减少垃圾回收时间和内存使用。然而，这是一个折衷：较低的堆限制减少了内存使用，但增加了垃圾回收时间。设置堆限制的经典方法包括手动调优堆限制和多个实时大小的经验法则，但尚不清楚何时一个规则优于另一个规则或如何比较它们。我们用一个新的框架来解决这个问题，在这个框架中，一次为多个堆设置堆限制。我们的关键见解是，每个堆限制规则都会导致跨多个进程的特定内存分配，并且这种分配可能是次优的。我们使用我们的框架来推导出最佳的“平方根”堆限制规则，该规则可以在任何总垃圾回收时间内最小化总内存使用量。奇怪的是，平方根堆限制规则在没有通信的情况下实现了这种协调：它在多个堆之间最优地分配内存，而不需要这些堆之间的任何通信。为了证明这个堆限制规则是有效的，我们为V8（Google Chrome、微软Edge和其他浏览器中使用的JavaScript运行时）以及服务器端框架（如node.js和Deno）建立了原型。在现实世界的网页，我们的原型实现了约16.0%的内存使用减少，同时保持垃圾回收时间不变。在内存密集型基准测试中，可以在不改变总内存使用量的情况下减少多达30.0%的垃圾回收时间。
2022-09-25 cs.PL cs.SY eess.SY
Opportunistic ZGC: Leveraging Idle Cores for More Effective Concurrent Garbage Collection
Oak Ridge National Laboratory（橡树岭国家实验室）
针对ZGC默认保守调度导致堆使用浪费的问题，提出反馈驱动的OppZGC策略，动态利用空闲CPU核心进行并发回收，自动约束堆大小，在DaCapo基准上平均降低最大堆使用61%-90%，且对性能影响极小。
2026-09-23 cs.DC cs.PF cs.PL
Pathological Cases for a Class of Reachability-Based Garbage Collectors
Stanford University（斯坦福大学）
本文证明了所有能实现现实互操作观察者接口的垃圾收集器都存在病态程序，迫使它们产生长暂停或拒绝分配，因此语言设计者需接受这些病态行为或限制程序行为。
2025-12-17 cs.PL
Live Objects All The Way Down: Removing the Barriers between Applications and Virtual Machines
提出活元循环运行时（LMRs），消除应用与虚拟机分离，使双方开发者都能用活编程工具调试和修改虚拟机，并在Bee/LMR中验证其可行性。
2023-12-28 cs.PL
