RE: Garbage collection

["Nick Trout" <ntrout@...>]

> On Behalf Of Thatcher Ulrich
> Sent: Wednesday, October 23, 2002 4:23 PM
>
> I think the existing Lua API should be adequate -- a lua_ref just
> increments the object's ref count when it's created via lua_ref(), and
> decrements it when it's destroyed via lua_unref().  No need to expose
> the concept of the ref count outside of the core.

There may be a slight performance issue here, and I think this is why
Python lets you handle referencing directly. Consider a swap function:
after you have swapped the values of the variables the reference count
is exactly the same, but if you reference count through the API then
you'll increment and decrement the count on the variables whilst
swapping, when its actually unncesssary. Python allows "deferred"
reference counting so that you can just tot up the necessary counts
afterwards. Actually Lua the assignment (as opposed to C) may be
slightly easier as you can do "a,b=b,a" but you get the point. I think
any extra cost incurred here is outweighed by the hiding of the whole
system.

http://www.iecc.com/gclist/GC-algorithms.html#Variations "Deferred
reference counting"


> On Behalf Of David Bhowmik
> Sent: Thursday, October 24, 2002 9:45 AM
> 
> The patch is pretty nasty. It replaces a few of the functions 
> in lgc and
> also the setting of globals and table objects so that all 
> assignments are
> referenced and unreferenced accordingly. 

Do you just use lua_ref and unref?

> it uses the 'marked' field in strings and userdata structures counting
negatively so as not 
> to be confused with reserved string references, and uses the 'mark'
pointer field in
> closures etc as an int as this is no longer required for 
> chaining objects when marking. Ugly I know, but it means not having to
rework 
> loads of lua. 

So as it stands you cannot use the M&S GC without seperating this out.

> There is only a need to mark the stack, tag functions and 
> locked objects,
> everything else is marked by its reference count. The 
> collection is spread
> so as to do a portion of the collection every time it is 
> called. 

If everything is marked, can you not free it when the ref count (with no
mark) is 0? I assume you can't do this because you something nasty might
happen in the Lua executor and you'd rather free stuff outside of there.

> We are
> using it for a real time agent system so we call it directly 
> ourselves a few
> times a second. We are running a couple of hundred agents 
> each updating
> twenty times a second and creating and discarding loads of 
> user types every
> time they do this. The patch has removed the gc stammer from 
> our engine.

[in the tone of Mr Burns] Excellent 

> I haven't as yet sorted anything for circular referenced 
> islands and am at
> present throwing an error if anyone does this. Does anyone 
> have any good
> policies for dealing with this?

Reenable M&S GC and call that! Perhaps once its made generational,
working with the RC objects, the hit will be minimal.

-- cyclic references
A = {}
B = { a = A }
A.b = B

A = nil -- should not delete A even if we meant to

I guess there are a few strategies: 
- Use an algorithm to determine where the islands are and delete them
(eg. M&S).
- Remove the cyclic dependencies so the object will be deleted.
- Use an interface that will prevents cyclic dependencies (proxies?):

Eg.
A = {}
B = { a = function() return A end }
A.b = function() return B end

A = nil
C = B.a() -- is now nil (untested!)

This is more inefficient and complicated. It is just a suggestion but if
used sparingly may help.

Regards,
Nick