Re: Thinking about Lua memory management

["Russell Y. Webb" <rw20@...>]

To continue, any incremental Lua gc scheme is going to have to figure out
how to traverse tables that may ultimately contain a link to everything.
Marking a table as already traversed will help; no need to go over things
more than once (surely Lua already does that).

But stopping in the middle of a mutable table could present some problems
--- I guess you could maintain some sort of modification counter for each
table and if you get foiled a few times incrementally getting through a
table then you'll have to just iterate over all of it at once.  Then if that
table can reach all luaobjects then you've got a worse case performance.
However since you can stop on table boundaries safely it's probably still
fairly good.

Russ

> From: "Russell Y. Webb" <rw20@cornell.edu>
> Reply-To: lua-l@tecgraf.puc-rio.br
> Date: Wed, 19 Sep 2001 01:23:13 -0700
> To: Multiple recipients of list <lua-l@tecgraf.puc-rio.br>
> Subject: Re: Thinking about Lua memory management
> 
>> Both of these ideas require adding some code to the Lua interpreter
>> everywhere
>> a pointer to a heap object is written to.
> 
> You can do incremental collection by only adding code everytime an object is
> allocated as long as it's marked as "in use".  Then you incrementally scan
> through everything marking things "in use" that you can reach, then
> incrementally free everything else, and then incrementally unmark everything
> and start over.  
> 
> I even have a untested allocator of this sort somewhere that has hooks
> traversing through whatever you allocate (I'll look for it).  The collector
> just has different incremental phases and new allocations are not ever
> cleaned up until a full cycle passes which you can of course force to happen
> whenever you want.
> 
> Russ
>