source/blog/posts/2008/08/reference-counting.rst

   1 Title: Reference counting worth a try
   2 Tags: en, d, dgc, intro, rc
   3
   4 Even when `I said`__ that `reference counting`__ (RC) will be hard
   5 in D__, I think it worth a try because it's a really easy way to get
   6 incremental garbage collection; the collector activity is interleaved
   7 with the mutator. And besides it could be hard to add support to the
   8 compiler, it's doable by manually incrementing and decrementing the
   9 reference counters to evaluate it.
  10
  11 __ https://proj.llucax.com.ar/blog/dgc/blog/post/361c2fb9
  12 __ http://en.wikipedia.org/wiki/Reference_counting
  13 __ http://www.digitalmars.com/d/
  14
  15 One of the biggest features of RC is its capability to identify garbage
  16 cells as soon as they become garbage (let cycles outside that statement
  17 =). The *killer* use for this is *finalization* support. Unfortunately
  18 this feature *kills* a lot of possible optimizations. On the other
  19 hand, D doesn't need finalization support very hard (with the scope__
  20 statement and other possible RAII__ `D techniques`__, I think nobody
  21 is missing it), so, lucky us, we can drop that feature and think about
  22 some optimizations.
  23
  24 __ http://www.digitalmars.com/d/1.0/statement.html#ScopeGuardStatement
  25 __ http://en.wikipedia.org/wiki/RAII
  26 __ http://www.digitalmars.com/d/1.0/memory.html#raii
  27
  28 RC can help too to all the fuzz about concurrency and `sharing in D2`__
  29 (it's trivial to know when an object is unshared), but that's a different
  30 story.
  31
  32 __ http://bartoszmilewski.wordpress.com/2008/07/30/sharing-in-d/
  33
  34 .. note::
  35     By the way, I don't think RC can make it on his own (yes, because of
  36     cycles), but I think it can help a lot to make collection incremental,
  37     leaving just a very small ammount of work to a tracing collector.
  38
  39 .. vim: set et sw=4 sts=4 :