Difference between revisions of "Versus the garbage collector"
m (one more link) |
(add links to Boehm) |
||
| Line 51: | Line 51: | ||
* http://forum.dlang.org/post/bsqqfmhgzntryyaqrtky@forum.dlang.org | * http://forum.dlang.org/post/bsqqfmhgzntryyaqrtky@forum.dlang.org | ||
* http://forum.dlang.org/post/l34lei$255v$1@digitalmars.com | * http://forum.dlang.org/post/l34lei$255v$1@digitalmars.com | ||
| + | * http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html (About the Boehm GC, but generally interesting) | ||
Revision as of 08:25, 15 January 2014
The big discussion about the garbage collector repeatedly comes up. This page tries to provide a summary.
Contents
Why GC is bad
- Unpredictable pauses which stop the world
- Current implementation sucks
Why GC is good
- Safe by default and non-leaking memory management
- Acceptable performance for many cases
- Supports immutable types
Common Ground
- We want something, which is safe by default
Proposals
Compiler-supported Reference Counting
Compiler generates reference counting for all references
- Pro: More predictable
- Pro: No manual rewriting necessary
- Contra: Cycles would leak
- Contra: Overhead due to inc/dec operations
- Open question: Does ARC guarantee memory safety?
Library Reference Counting
Use std.typecons.RefCounted
- Pro: Garbage collector still provides safety
- Contra: Lots of manual work
- Contra: Overhead due to inc/dec operations
DIP18: nogc attribute
- Pro: Compile-time checked
- Pro: Selective usage
- Contra: Attribute creep
Implement Certain Interface
- Cannot find original thread
Links
- http://forum.dlang.org/post/bsqqfmhgzntryyaqrtky@forum.dlang.org
- http://forum.dlang.org/post/l34lei$255v$1@digitalmars.com
- http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html (About the Boehm GC, but generally interesting)
