source/blog/posts/2009/03/accurate-garbage-collection-in-an-uncooperative-environment.rst

   1 Title: Accurate Garbage Collection in an Uncooperative Environment
   2 Tags: en, d, dgc, paper, tracing, accurate, henderson, uncooperative environment
   3
   4 I just read `Accurate Garbage Collection in an Uncooperative Environment`__
   5 paper.
   6
   7 __ http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570
   8
   9 Unfortunately this paper try to solve mostly problems D don't see as problems,
  10 like portability (targeting languages that emit C code instead of native
  11 machine code, like the Mercury__ language mentioned in the paper). Based on the
  12 problem of tracing the C stack in a portable way, it suggests to inject some
  13 code to functions to construct a linked list of stack information (which
  14 contains local variables information) to be able to trace the stack in an
  15 *accurate* way.
  16
  17 __ http://www.cs.mu.oz.au/research/mercury/
  18
  19 I think none of the ideas presented by this paper are suitable for D, because
  20 the GC already can trace the stack in D (in an unportable way, but it can), and
  21 it can get the type info from better places too.
  22
  23 In terms of (time) performance, benchmarks shows that is a little worse than
  24 `Boehm (et al) GC`__, but they argue that Boehm has years of fine grained
  25 optimizations and it's  tightly coupled with the underlying architecture while
  26 this new approach is almost unoptimized yet and it's completely portable.
  27
  28 __ http://www.hpl.hp.com/personal/Hans_Boehm/gc/
  29
  30 The only thing it mentions that could apply to D (and any conservative GC in
  31 general) is the issues that compiler optimizations can introduce. But I'm not
  32 aware of any of this issues, so I can't say anything about it.
  33
  34 In case you wonder, I've added this paper to my `papers playground page`__
  35 =)
  36
  37 __ /proj/dgc/papers.html
  38
  39
  40 Update
  41 ------
  42
  43 I think I missed the point with this paper. Current D GC **can't** possibly do
  44 accurate tracing of the stack, because there is no way to get a type info from
  45 there (I was thinking only in the heap, where some degree of *accuracy* is
  46 achieved by setting the ``noscan`` bit for a *bin* that don't have pointers, as
  47 mentioned in my `previous post`__).
  48
  49 __ /blog/blog/post/250bf643
  50
  51 So this paper could help getting accurate GC into D, but it doesn't seems
  52 a great deal when you can add type information about local variables when
  53 emitting machine code instead of adding the *shadow stack* linked list. The
  54 only advantage I see is that I think it should be possible to implement the
  55 linked list in the front-end.
  56
  57 .. vim: set et sw=4 sts=4 :