Boehm 垃圾收集器中的精确模式

发布于 2024-11-25 07:29:23 字数 164 浏览 3 评论 0原文

我在 Mono 的网页上看到他们正在精确模式下使用 Boehm GC。我也使用带有 C++ 的 Boehm GC,但是,我在其文档或标题中没有找到任何可以指示精确模式的内容,更不用说如何打开它了。

是否有任何信息表明它实际上默认具有精确模式以及如何打开它,或者它只是 Mono 开发人员的某种修改?

I've read on the webpage of Mono that they are using the Boehm GC in precise mode. I too use the Boehm GC with C++, however, I have found nothing in its documentation or headers that would indicate a precise mode, much less how to turn it on.

Any information whether it actually has a precise mode by default and how to turn it on, or it was just some kind of modification by Mono developers?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

段念尘 2024-12-02 07:29:23

Mono 下 Boehm GC 中的精确模式不仅仅是 GC_MALLOC_ATOMIC。仅适用于基本类型的数组。

对于托管类型,使用GC_gcj_malloc。 Mono 的编译器为每个托管类型生成一个对象描述符,然后只需使用大小参数和指向托管类型描述符的指针调用 GC_gcj_malloc 即可。然后,Boehm GC 在标记阶段引用描述符来跟踪托管指针。

最终,您将仅将根指针作为原始指针放在堆栈上(GC_gcj_malloc 返回 void*,并且无法通过某种堆栈告诉 GC 指针在堆栈上的位置GC 收集之前的描述符)。这就是 Mono(SGen 之前)说他们以保守模式扫描堆栈的原因。

如果您想在 C++ 下实现这一点,您将无法简单地依赖 C++ 编译器为您生成对象描述符。我很久以前的设想是编写一个中间编译器,它可以解析所有 C++ 头文件以查找已标记为托管类的类定义(例如 _ref class MyManagedObject where _ref 只是一个#define 到什么都没有)并生成一个包含这些对象描述符的头文件。然后,您可以使用 GC_make_descriptor 和 GC_malloc_explicitly_typed 函数以精确模式而不是 GC_gcj_malloc 来分配对象,因为您无法控制 C++ 的分配方式编译器分配其 vtable。

*编辑:请参阅GCC 托管 C++(开源 GPL v3)

Precise mode in Boehm GC under Mono isn't just GC_MALLOC_ATOMIC. It's only true for arrays of fundamental types.

For managed types, GC_gcj_malloc is used. Mono's compiler generates an object descriptor for every managed type and it then simply calls GC_gcj_malloc with an argument of size, and a pointer to the managed type's descriptor. Boehm GC then refers to the descriptor during mark phase to trace the managed pointers.

You will end up with just the root pointers sitting on the stack as raw pointers (GC_gcj_malloc returns a void* and there's no way to tell the GC where the pointers are on the stack via some sort of a stack descriptor prior to GC collect). This is the reason Mono (prior to SGen) says they scan the stack in conservative mode.

If you want to implement this under C++, you won't be able to simply rely on the C++ compiler to generate the object descriptor for you. What I envisioned a long time ago was to write an intermediate compiler that parses all your C++ header files for class definitions that have been marked as managed class (e.g. _ref class MyManagedObject where _ref is simply a #define to nothing) and generate a header file containing those object descriptors. You would then use the GC_make_descriptor and GC_malloc_explicitly_typed functions to allocate your objects in precise mode rather than GC_gcj_malloc as you would not have control over how your C++ compiler allocates its vtable.

*EDIT: See Managed C++ for GCC (open source GPL v3).

情释 2024-12-02 07:29:23

来自垃圾收集器的文件 doc/gcinterface.html (archive这里)指出:

void * GC_MALLOC_ATOMIC(size_t nbytes)
分配 n 字节的存储空间。需要(摊销)时间
与 nbytes 成正比。生成的对象将自动
未引用时释放。客户承诺所产生的结果
对象永远不会包含任何指针。内存没有被清除。
这是分配字符串、浮点数组的首选方式,
位图等。有关指针位置的更精确信息可以是
使用 gc_typed.h 中的接口与收集器通信
分布。

看起来有一个“精确”的接口可以使用。

The file doc/gcinterface.html from the garbage collector (archive here) states:

void * GC_MALLOC_ATOMIC(size_t nbytes)
Allocates nbytes of storage. Requires (amortized) time
proportional to nbytes. The resulting object will be automatically
deallocated when unreferenced. The client promises that the resulting
object will never contain any pointers. The memory is not cleared.
This is the preferred way to allocate strings, floating point arrays,
bitmaps, etc. More precise information about pointer locations can be
communicated to the collector using the interface in gc_typed.h in the
distribution.

It looks like there is a "precise" interface that can be used.

錯遇了你 2024-12-02 07:29:23

我相信精确模式需要编译器的支持来准确指示指针的存储位置。 C 和 C++ 中的类型转换使得这几乎不可能。

具有内置反射的托管语言将使这变得容易得多。

I believe the precise mode needs support from the compiler to indicate exactly where pointers are stored. Typecasting in C and C++ makes this next to impossible.

A managed language, with built in reflection, would make this a lot easier.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文