RE: GC order

["Bilyk, Alex" <ABilyk@...>]

So Lua is free of circularity problems? Does this mean that if A referred to B and B referred to A, there is a way in Lua one can somehow cause garbage-collection on either A or B? I was under impression it would have been the case where neither one would get GCed. I guess I am not sure what a circularity problem is. Hmm...

Alex.

-----Original Message-----
From: 	Marc Nijdam [mailto:mnijdam@qualcomm.com] 
Sent:	Thursday, May 08, 2003 3:55 PM
To:	Multiple recipients of list
Subject:	RE: GC order

Most reference based systems suffer from circularity problems and require 
careful consideration from the "user" of the components.

-men

At 13:52 5/8/2003 -0700, you wrote:
>OK,
>I think I have all the answers I needed. I am using IDs to identify 
>co-routines, which gives me full control over their life time as far the 
>application code is concerned.
>
>By the way, why not to use object reference counts and base garbage 
>collection on these. As soon as the ref count goes to 0 there is no doubt 
>the object can be collected and it's very easy to write GC incremental or 
>not. Granted, Lua will be a notch slower and perhaps lager but how much 
>slower I wonder? Every time a new reference to the object is created the 
>count goes 1 up. Every time the reference being removed the count goes 1 
>down. Removing items off the stack would be suffering the most I would 
>guess. I am just wondering if you have ever considered this as an option 
>for Lua's GC.
>
>Thanks you,
>Alex.
>
>  -----Original Message-----
>From:   RLake@oxfam.org.uk [mailto:RLake@oxfam.org.uk]
>Sent:   Thursday, May 08, 2003 1:07 PM
>To:     Multiple recipients of list
>Subject:        Re: GC order
>
>
> > You can do that. First, you must store the userdata in the coroutine
> > (e.g., in its stack, or in its global table, if it has a separated
> > global table). So, the userdata cannot be collected before the coroutine.
>
> > Then, you must store an entry (userdata -> coroutine) in a table with
> > weak keys (but strong values). That entry will not prevent the userdata
> > from being collected. The main point here is that a weak key is only
> > cleared *after* its __gc method runs. That means that, when the __gc
> > method runs, you still can safely retrieve the coroutine from this
> > table. (This is not by chance; it is the reason why weak keys are
> > only cleared after running the __gc methods).
>
>Sorry, Roberto, but that won't work. I have pointed this out a few times.
>
>The weak table has a strong reference to the coroutine. Strong references
>are marked and traversed. The coroutine has a reference to the userdata. So
>the userdata is marked. So the reference to the coroutine is never deleted
>from the weak table. Consequently neither the coroutine nor the userdata
>will ever get collected.
>
>See <http://lua-users.org/wiki/GarbageCollectingWeakTables>
>
>gentoo lua-5.0 # bin/lua
>Lua 5.0  Copyright (C) 1994-2003 Tecgraf, PUC-Rio
> > -- Create an object b
> > b = {}
> > -- Create a which refers to b
> > a = {b}
> > -- create a weaktable in which b points to a
> > weak = setmetatable({}, {__mode = "k"})
> > weak[b] = a
> > -- Get rid of the only references to a and b other than the weak one
> > a, b = nil, nil
> > -- what's in the table?
> > table.foreach(weak, print)
>table: 0x8069e38        table: 0x806a0b8
> > -- garbage collect a few times
> > collectgarbage()
> > collectgarbage()
> > collectgarbage()
> > collectgarbage()
> > -- what's in the table?
> > table.foreach(weak, print)
>table: 0x8069e38        table: 0x806a0b8