Difference between revisions of "Versus the garbage collector"

From D Wiki
Jump to: navigation, search
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.


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