lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Thanks for the response, Jonathan.

> -----Original Message-----
> From: Jonathan Branam [] 
> > Yep, here we go again.
> It never ends... :>

Yes.  The speed of the garbage collection has been a glaring issue for
real-time applications for some time.  I think that the Lua community
and Lua team should discuss some real possibilities to allow the garbage
collection to run more reasonably in real-time environments.

> I explored this briefly. What I realized was that there are 
> many, many cases which "de-reference" a piece of data. 
> Catching all of these is quite difficult. 

Initially, I thought that the values in Lua were reference counted.
This isn't true, so any form of checking the reference for 0 is out.

> - Passing the end of a block removes all local variables
> - Passing out of a function removes all function parameters
> - Returning from a function, and not using all the return values
> - Anytime lua_settop() or lua_pop() is called from C to pop the stack.
> - Assigning an existing variable to a new value
> - lua_unref() from C
> - GC of a table
> - GC of a function (I think at least the upvalues become dereferenced)

Perhaps a list of modified Lua values this frame might be in order.
Then only those values (and their associated keys) have to be checked.
There are probably many holes in this idea, but I definitely see it as
faster than what's there.

> However, I believe you could add a simple function/VM 
> instruction (not sure which is really required) to 
> de-allocate values at will. What this means is that you have 
> to go back and find all times in the script which would cause 
> a de-allocation and put this instruction there.

This would be difficult, as you suggest, and is likely to change in
other versions of Lua.

Joshua Jensen
Amped: Freestyle Snowboarding