On Sun, Apr 28, 2013 at 6:07 PM, SASADA Koichi <ko1@atdot.n= et> 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-barri= ers have old values too (e.g "An On-the-Fly Mark and Sweep Garbage Col= lector 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 (sli= de
> 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 r= equired if you have multiple threads running at the same time. In CRuby the= re will only be a single thread running Ruby code so this becomes easier. F= or a concurrent tracer (tracing/marking objects as the Ruby thread runs) th= e most important thing is to get a consistent view of the heap.

Example:

(1) Tracer starts running in the background

(2) a =3D ob= ject.thing; object.thing =3D nil

(3) Tracer reaches `object= `, doesn't find `a`, frees it

(4) object.thing =3D a, dangling pointer

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

If we have the sunny/shady-distinction it m= ight 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

--001a11c34dce18437104db6e205f--