Re: GC Parameters & Emergency Collection

Posted by Robert G. Jakabosky on
URL: http://elua-development.15.s1.nabble.com/GC-Parameters-Emergency-Collection-tp2846858p2850280.html

Hello eLua list,

I am the creator of the Emergency Garbage Collection (EGC) patch for Lua
5.1.x.  I joined this list because I have interest in using Lua VM with a
very low memory limit and I think that over laps with embedded systems.

Attached is a version of the EGC patch for eLua SVN revision 281.  I just had
to updated line numbers so it would apply cleanly to eLua without any
warnings.

I have only done minimal testing.  Had problems with getting newlib compiled
on my 32bit Gentoo linux box so that I could test eLua standalone inside
Vmware.  So I ended up only testing eLua's modified copy of Lua as a linux
app. and only tested life.lua and bisect.lua (I just pick two from the romfs
folder).  life.lua was able to run with the memory limit set to 60Kbytes.  
The attched 'linux_host.patch' file are the changes I made to eLua so I could
test it.

For testing & debugging what tools do other people use?  Remote gdb over
serial?  I might be able to do more testing tomorrow, right now I am to
tired.

On Friday 08, James Snyder wrote:
> Additionally: I've looked at the emergency GC patch minimally, and it
> looks fairly extensive.  I suppose this wouldn't work in all cases
> (presumably since GC may sometimes require memory to grow a bit before
> shrinking), but would it not be useful to attempt a GC when a new
> allocation fails?  I've thought about attempting to apply the
> emergency GC patch to eLua, but I've not bothered because 5.2 is
> intended to include some sort of emergency GC.

About 2/3 of the EGC patch is to make the resizing of the internal string
table & hashpart of Lua table use less memory.  That is done by doing an
in-place resize of those tables.  If the table is shrinking then the nodes
are moved to the start of the table then realloc is called to shrink the
table.  If the table is growing then the realloc is done first before the
nodes are moved.  All of these changes are in lstring.c & ltable.c and I
don't see any conflict with the change eLua made to vanilla Lua.

The only place where the GC needed to grow memory usage before shrinking usage
is when it is trying to shrink the internal string table or the hashpart of
Lua tables.

> Another thought:  One of the reasons we don't have determinism in
> execution times is because of GC.  I've not dug into how the Lua GC
> works, but is there some way that we could have it operate in some
> sort of fixed execution time mode where with debug hooks where we
> could run it for a fixed length of time at that frequency to control
> latency?

I think you could improve the determinism of the GC by changing the
luaC_step() function to limit each incremental GC step to some fixed length
of time (or cpu cycles if that is cheap to test).  This should be a simple
change to the luaC_step() function, since it already calls the singlestep()
function multiple times until X number of bytes have been freed or the end of
the current GC cycle has been reached.

I still think that low memory systems should use the EGC to fully utilize the
limited memory they have.

--
Robert G. Jakabosky

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev