问题标签 [boehm-gc]

boehm-gc 7.6 处于预发布状态，boehm-gc 7.6 什么时候发布？
我们现在可以在产品中使用它吗？我找不到发布计划或任何路线图。谢谢！

我在 Android x86 上的 Boehm 发生了一次奇怪的崩溃（但 arm 工作正常）；它正在崩溃：

和：

LogCat：I/DEBUG（6453）：信号 11（SIGSEGV），代码 1（SEGV_MAPERR），故障地址 0xa31f8

它总是失败的相同地址（0xa31f8）；现在这可能是我做错了。这是一种自定义语言，我只是链接到 libc.so。什么可能导致这种情况？

日志：

LogCat：I/BDWGC（7930）：分配 0 个字节后堆增加到 64 KiB

LogCat: D/BDWGC (7930): 创建线程 0xb7795160

LogCat：D/BDWGC（7930）：从 0xb7795160 停止世界

LogCat：D/BDWGC（7930）：世界从 0xb7795160 停止

LogCat：D/BDWGC（7930）：从线程 0xb7795160 推送堆栈

LogCat: D/BDWGC (7930): Stack for thread 0xb7795160 = [0xbf90be1c,0xbf90f000) LogCat: F/libc (7930): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xa31f8 in tid 7930 (ksample.oxygene)

回溯：

(gdb) BT

#0 0xa502c9ad in GC_mark_from (mark_stack_top=0xb8b30010, mark_stack=0xb8b30000, mark_stack_limit=0xb8b38000) at mark.c:853

#1 0xa502c1d0 in GC_mark_some (cold_gc_frame=0xbf90beec "l¿\220¿Hò\001¥ì¾\220¿") 在 mark.c:409

#2 0xa501f248 in GC_stopped_mark (stop_func=0xa501e420) at alloc.c:702

#3 0xa501eed2 in GC_try_to_collect_inner (stop_func=0xa501e420) at alloc.c:488

#4 0xa50254ff in GC_init () at misc.c:1288

CPython 是一个多线程应用程序，因此在 Unix 上它使用 (p) 线程。Python 扩展（比如用 C 语言编写）通常需要持有 GIL 以确保 Python 对象不会在代码的关键部分损坏。其他类型的数据呢？具体来说，在 Python 扩展中持有 GIL 是否保证 CPython 的所有其他线程都停止？

询问的原因是我试图将 Python 扩展（适用于 Linux 和 OSX）移植到 FreeBSD，该扩展使用 Boehm GC 嵌入 Lisp 编译器/系统ECL，并且在嵌入式 Boehm GC 的初始化期间崩溃。回溯表明另一个线程启动并造成严重破坏（Linux 上的 pthread 实现与 FreeBSD 的实现有很大不同，因此预计也会出现这些问题）。CPython 中是否有另一个互斥锁可用于实现锁定？

我在mingw32项目中使用gc，遇到如下问题：程序静态链接时，没有问题，程序运行正常。但是，在将某些组件移动到 dll 后，程序崩溃了。有什么建议吗？问候， bostjanv

是否可以将 Qt 与 BDW-GC 一起使用？我知道 Qt 有一个复杂的内存管理系统，但我的部分实现无论如何都会使用 GC，所以不打扰并始终使用它会很方便。

据我所知，一个问题可能是 Qt 具有特定的析构函数，必须在释放对象时调用这些析构函数。所以我可能不得不手动注册终结器，它调用析构函数。

无论如何，我还没有找到很多关于使用 Qt 和 BDW-GC 的信息。这就是我问的原因。

我正在用 guile 开发一个应用程序，但我遇到了一些奇怪的错误。我怀疑这些错误是由 guile 或它使用的某些库中的未初始化变量引起的。guile 版本 2.0 和 2.2 都会出现此问题。

当我使用 valgrind 运行 guile 时，出现以下错误（以及其他错误）：

我在函数 GC_with_callee_saves_pushed 中找不到任何未初始化的值。我试图将 GC_with_callee_saves_pushed 中的上下文变量 memset 为 0，但它没有帮助。跟踪中 GC_with_callee_saved_pushed 的第二个参数来自 alloc.c 的第 702 行中对 GC_approx_sp 的函数调用。

GC_with_callee_saves_pushed 中编译的条件分支是“#if defined(UNIX_LIKE)...”之后的分支。"#if defined(HAVE_BUILTIN_UNWIND_INIT)" 的 else 分支未编译。

这个错误是否与 此类似

你有什么想法如何推进这件事吗？

Boehm gc 只处理内存分配。但是如果要使用垃圾收集来处理fopen()那么fclose()就不再需要了。有没有办法在C中这样做？

PS 例如，PyPy 采用垃圾回收的方式来处理打开文件。

最明显的影响是文件（和套接字等）超出范围时不会立即关闭。对于为写入而打开的文件，数据可能会在其输出缓冲区中保留一段时间，从而使磁盘上的文件显示为空或被截断。

http://doc.pypy.org/en/latest/cpython_differences.html

我在 Unity 的Boehm–Demers–Weiser 垃圾收集器上运行，它是一种非分代 GC。

我在内存中有一大棵托管对象树（~100k 个对象，~200MiB 分配）。

这些对象本质上是一个缓存并且永远不会超出范围，因此它们实际上永远不会被 GC 清除。

然而，因为 Boehm 是非代际的，所以这个陈旧的缓存永远不会被提升到更高的代。这会导致标记阶段花费大量的处理时间，因为它必须在每个集合上遍历整个缓存，从而导致明显的延迟峰值。

正如 Unity 文档所说，这是“设计使然” ：

至关重要的是，Unity 的垃圾收集（使用 Boehm GC 算法）是非分代和非压缩的。“非分代”意味着 GC 在执行收集过程时必须扫描整个堆，因此其性能会随着堆的扩展而下降。

我很清楚减少重复性垃圾分配的方法，但是我找不到有关如何在非分代 GC 中优化大型、陈旧的基线分配的任何信息。

进一步来说：

• 有没有办法将根指针（例如静态字段）标记为完全被 GC 忽略？
• 在标记阶段是否有一些数据结构模式可以更快地遍历？
• 相反，是否存在阻碍标记阶段速度的已知数据结构模式？

这些问题只是我解决这个问题的一些假设，但我愿意接受所有建议。

根据手册，GC_MALLOC清除内存但GC_MALLOC_ATOMIC不清除内存。

https://www.hboehm.info/gc/gcinterface.html

那么GC_MALLOC_ATOMIC应该用来代替malloc还是 GC_MALLOC应该用来代替calloc呢？是这样吗？

我有一个使用 Boehm GC 实现的个人项目。我需要实现一种事件类型，它应该包含对其他事件的引用。但我还需要确保指向的事件仍然是可收集的，因此我需要弱引用。

假设我们有事件 A、B 和 C。我将这些事件配置为在发出任何信号时发出事件 X 的信号。这意味着 A、B 和 C 必须持有对事件 X 的引用。我想要的是，如果事件 X 不可访问，则事件 A、B 和 C 不再需要发出信号。因此，我想到的是弱参考。

有没有其他方法可以做到这一点？我不想更改 GC，但如有必要（分配界面保持干净）我可以。

该项目是用 C 编写的。如果需要，我将提供更多信息。值得注意的是，如果有任何方法可以直接使用这种语义实现此类事件，则不需要实际的弱引用（事件可能有一个引用周期，尽管它们没有发出信号）。