为什么没有为C设计垃圾回收有特定的原因吗? [英] Was there a specific reason why garbage collection was not designed for C?

问题描述

我听说C自动收集垃圾不是最佳选择-这有什么道理吗?

I have heard that it was suboptimal for C to automatically collect garbage — is there any truth to this?

是否有没有针对C实施垃圾回收的特定原因?

Was there a specific reason garbage collection was not implemented for C?

推荐答案

不要听"C很旧，这就是为什么它没有GC"的原因.乡亲.GC存在一些无法解决的基本问题，这使其与C不兼容.

Don't listen to the "C is old and that's why it doesn't have GC" folks. There are fundamental problems with GC that cannot be overcome which make it incompatible with C.

最大的问题是，准确的垃圾回收需要扫描内存并识别遇到的任何指针的能力.一些高级语言限制整数不使用所有可用位，以便可以使用高位来区分对象引用和整数.然后，此类语言可以将字符串(可以包含任意八位字节序列)存储在一个特殊的字符串区域，在该区域中它们不能与指针混淆，一切都很好.但是，C实现无法执行此操作，因为字节，较大的整数，指针和其他所有内容都可以一起存储在结构，联合或作为 malloc 返回的块的一部分中.

The biggest problem is that accurate garbage collection requires the ability to scan memory and identify any pointers encountered. Some higher level languages limit integers not to use all the bits available, so that high bits can be used to distinguish object references from integers. Such languages may then store strings (which could contain arbitrary octet sequences) in a special string zone where they can't be confused with pointers, and all is well. A C implementation, however, cannot do this because bytes, larger integers, pointers, and everything else can be stored together in structures, unions, or as part of chunks returned by malloc.

如果您放弃准确性要求并确定您对某些对象没有问题，因为程序中的某些非指针数据具有与这些对象的地址相同的位模式，该怎么办?现在，假设您的程序从外界(网络/文件/等)接收数据.我声称我可以使您的程序泄漏任意数量的内存，并最终用尽内存，只要我能猜出足够多的指针并将它们模拟在我提供给您的程序的字符串中即可.如果您应用 De Bruijn序列，这会变得容易得多.

What if you throw away the accuracy requirement and decide you're okay with a few objects never getting freed because some non-pointer data in the program has the same bit pattern as these objects' addresses? Now suppose your program receives data from the outside world (network/files/etc.). I claim I can make your program leak an arbitrary amount of memory, and eventually run out of memory, as long as I can guess enough pointers and emulate them in the strings I feed your program. This gets a lot easier if you apply De Bruijn Sequences.

除此之外，垃圾回收速度很慢.您可以找到数百名愿意提出其他主张的学者，但这不会改变现实.GC的性能问题可分为3个主要类别:

Aside from that, garbage collection is just plain slow. You can find hundreds of academics who like to claim otherwise, but that won't change the reality. The performance issues of GC can be broken down into 3 main categories:

• 不可预测性
• 缓存污染
• 花费所有内存的时间

如今声称GC速度很快的人们只是将它与错误的事物进行比较:编写不良的C和C ++程序每秒分配并释放成千上万个对象.是的，这些也会很慢，但是至少可以预见的是，如果需要的话，您可以通过某种方式对其进行测量和修复.编写良好的C程序将花费很少的时间在 malloc / free 中，以至于开销是无法衡量的.

The people who will claim GC is fast these days are simply comparing it to the wrong thing: poorly written C and C++ programs which allocate and free thousands or millions of objects per second. Yes, these will also be slow, but at least predictably slow in a way you can measure and fix if necessary. A well-written C program will spend so little time in malloc/free that the overhead is not even measurable.

这篇关于为什么没有为C设计垃圾回收有特定的原因吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！