From: Mike Owens Date: 2012-04-14T12:45:02+09:00 Subject: Re: GC on two C extension objects --e89a8f6428e6e652ef04bd9b692d Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Okay, thanks. I had not thought of cyclic dependencies. On Fri, Apr 13, 2012 at 7:49 PM, Peter Zotov wro= te: > Mike Owens =D0=C9=D3=C1=CC 13.04.2012 21:02: > >> I am running into a problem with to C extension objects and I'm not sure >> what I'm missing. I put together a simple example illustrating the point >> here: >> >> https://github.com/linterra/**ruby-c-ext-gc >> >> Basically one C extension class (child) references another (parent). To >> keep parent from being GC'd before the child referencing it, I assign a >> reference in the child using rb_ivar_set(). Additionally, I also add a >> mark >> function in the child to mark the parent. >> >> Still, when GC runs, the parent still gets cleaned up first and the chil= d >> GC segfaults because it references the GC'd parent. I can see that the >> child's mark function is being called. >> >> >> >> Mike >> > > This is the intended behavior. Objects are not sweeped in an order relate= d > to > their reference contents; instead, the mark phase just searches for islan= ds > of unused objects and sweep phase destroys these islands. Why does it wor= k > this way? Easy. First, there is no sensible sweep order in case of circul= ar > reference. Second, GC should be as fast as possible, and ensuring a > particular > order of sweeping would incur significant computational cost. > > You should keep all your data in a single "pivot" object and only return > thin > references to that data in accessors. Think of a DOM document and a node > list. > > -- > WBR, Peter Zotov. > > --=20 Mike --e89a8f6428e6e652ef04bd9b692d Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Okay, thanks. I had not thought of cyclic dependencies.

On Fri, Apr 13, 2012 at 7:49 PM, Peter Zotov <whitequark@whitequark= .org> wrote:

Mike Owens =D0=C9=D3=C1=CC 13.04.2012 21:02:=

I am running into a problem with to C extension objects and I'm not sur= e
what I'm missing. I put together a simple example illustrating the poin= t
here:

htt= ps://github.com/linterra/ruby-c-ext-gc

Basically one C extension class (child) references another (parent). To
keep parent from being GC'd before the child referencing it, I assign a=
reference in the child using rb_ivar_set(). Additionally, I also add a mark=
function in the child to mark the parent.

Still, when GC runs, the parent still gets cleaned up first and the child GC segfaults because it references the GC'd parent. I can see that the<= br> child's mark function is being called.

<snip>

Mike

This is the intended behavior. Objects are not sweeped in an order related = to
their reference contents; instead, the mark phase just searches for islands=
of unused objects and sweep phase destroys these islands. Why does it work<= br> this way? Easy. First, there is no sensible sweep order in case of circular=
reference. Second, GC should be as fast as possible, and ensuring a particu= lar
order of sweeping would incur significant computational cost.

You should keep all your data in a single "pivot" object and only= return thin
references to that data in accessors. Think of a DOM document and a node li= st.

--
=9AWBR, Peter Zotov.

-- Mike
--e89a8f6428e6e652ef04bd9b692d--