4 ms·

Sorry, that's wrong. The D programming language currently uses a conservative garbage collector. Before version 1.0, false pointers were a serious problem. The

Sorry, that's wrong. The D programming language currently uses a conservative garbage collector. Before version 1.0, false pointers were a serious problem. The most common causes of false pointers were: - ASCII text; - floating-point values; - high-entropy (compressed/encrypted) data, e.g. image files. Just 1 MB of random-ish data is enough to pin down allocations of 16 KB or bigger. And of course, it cascades through any false pointers in any pinned memory blocks, and so on. In D 1.0, the garbage collector now remembers whether any memory block contains any pointers or not. So, now it can tell whether any memory address either definitely contains no pointers, or may contain pointers. Even so, memory leaks due to false pointers on 32-bit are not unheard of. For personal use, I've had to write a tool to diagnose these memory leaks: https://github.com/CyberShadow/Diamond https://github.com/CyberShadow/Diamond Rainer Schuetze is working on improving the precision of the GC from one heap allocation block to one machine word, but there's still work to be done on this.

jgable 12y ago
So what are some strategies to really solve this problem? Is it basically impossible to implement a GC for a C-like language that will not leak at least a little memory?
- CyberShadow 12y ago
  It's not possible as long as your language has: - non-discriminated unions mixing pointers and non-pointers - linking with C or other languages (as you can't scan their stack frames precisely) - void*, memcpy, or other ways to move around memory which might have pointers. A language without all of the above would be of limited utility. However, it's possible to dramatically improve the situation using: - precise heap scanning - by knowing the type of each object allocated; - precise stack scanning - by knowing the stack layout of all functions at all points throughout their execution; - GC hooks for user-defined union types.

jgable 12y ago

So what are some strategies to really solve this problem? Is it basically impossible to implement a GC for a C-like language that will not leak at least a little memory?

CyberShadow 12y ago
It's not possible as long as your language has: - non-discriminated unions mixing pointers and non-pointers - linking with C or other languages (as you can't scan their stack frames precisely) - void*, memcpy, or other ways to move around memory which might have pointers. A language without all of the above would be of limited utility. However, it's possible to dramatically improve the situation using: - precise heap scanning - by knowing the type of each object allocated; - precise stack scanning - by knowing the stack layout of all functions at all points throughout their execution; - GC hooks for user-defined union types.