RE: Garbage collection

[David Bhowmik <david.bhowmik@...>]

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. 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. 

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. 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.

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?


-----Original Message-----
From: Nick Trout [mailto:ntrout@rockstarvancouver.com]
Sent: 24 October 2002 01:24
To: Multiple recipients of list
Subject: RE: Garbage collection




> [mailto:owner-lua-l@tecgraf.puc-rio.br] On Behalf Of Thatcher Ulrich
> Sent: Wednesday, October 23, 2002 4:23 PM

> I've been thinking about this a little -- the regular mark-sweep
> should be able to collect cyclic stuff, right?  So reference-counting
> is sort of an incremental collector for non-cyclic structures.  The
> great thing about reference counting is that it's simple and easy to
> understand.  Has David posted his patch publically?

If the patch is public then I don't know where it is. 

Maybe you could use the two together. Python has had to resort to this.
I believe their cyclic collector is a script library so Lua would have
the advantage of a faster C based one. I've no idea what algorithm they
use but I don't think its mark and sweep.
http://www.python.org/doc/current/lib/module-gc.html


> > It slightly complicates object management from the C side 
> because you
> > have to manage the reference count to Lua objects when you want to
> > reference them. There is potential for error here if don't 
> reference and
> > unreference them correctly. You may be able to hide all of 
> this in the
> 
> 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.

I havent had time to check and I don't know if there are differences in
Lua 5, but from what I remember you could use ref and unref as you
describe. I don't think you'd have to alter their functionality as they
are reference counting/locking Lua objects already. The internals of Lua
would, I think, need some work. So this patch will be interesting to
see.

You may get problems when you get "islands" of objects which the M&S
collector would delete but have C references to and should not be
deleted. Lua_ref() locks these objects for C. There may have to be a
separate counter for Lua internally which the C count would override.

A (total) reference count method to return the number of references to
an object would still be a very useful debugging tool for making sure
that you are releasing objects when you think you are. (eg. When you do
a obj=nil).

Nick