On Sun, Apr 28, 2013 at 6:07 PM, SASADA Koichi <ko1 / atdot.net> wrote:

> (2013/04/28 23:34), SASADA Koichi wrote:
> >> Another thing: What about passing the old value to OBJ_WB too?
> OBJ_WB(from, to, old)? In this implementation it would just be a no-op.
> There are some nice garbage collectors that you can implement if your
> write-barriers have old values too (e.g "An On-the-Fly Mark and Sweep
> Garbage Collector Based on Sliding Views").
> > Interesting. But I doubt that we can implement them (w/o incomplete
> > WBs). Anyway, I need to read a paper. If there are good resources (slide
> > pdf, etc) to know them, please tell them.
>
> Maybe I understand the snapshot idea.
> I don't think it is acceptable for CRuby (because CRuby moves memory
> areas!). But not for CRuby, it may considerable.


In hindsight I think that the sliding views-technique is only required if
you have multiple threads running at the same time. In CRuby there will
only be a single thread running Ruby code so this becomes easier. For a
concurrent tracer (tracing/marking objects as the Ruby thread runs) the
most important thing is to get a consistent view of the heap.

Example:

(1) Tracer starts running in the background
(2) a = object.thing; object.thing = nil
(3) Tracer reaches `object`, doesn't find `a`, frees it
(4) object.thing = a, dangling pointer

If you have a WB that records previous values you just need to add the
previous value to the marklist (e.g. `object.thing = nil` will add `a` to
the marklist).

If we have the sunny/shady-distinction it might be possible to (1) stop the
world, (2) mark all roots, trace all shady objects (3) start the world (4)
trace sunny objects concurrently. We just need a strategy for objects that
become shady during the concurrent tracing.

// Magnus Holm