[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Thinking about Lua memory management
- From: "Russell Y. Webb" <rw20@...>
- Date: Wed, 19 Sep 2001 10:02:50 -0700
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
> From: "Russell Y. Webb" <email@example.com>
> Reply-To: firstname.lastname@example.org
> Date: Wed, 19 Sep 2001 01:23:13 -0700
> To: Multiple recipients of list <email@example.com>
> Subject: Re: Thinking about Lua memory management
>> Both of these ideas require adding some code to the Lua interpreter
>> 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.