http://elua-development.15.s1.nabble.com/GC-Parameters-Emergency-Collection-tp2846858p2863481.html
On May 11, 2009, at 12:54 AM, Bogdan Marinescu wrote:
On Mon, May 11, 2009 at 6:34 AM, James Snyder
<[hidden email]> wrote:
Minimal testing seems to show it working and surviving through conditions where previously it would run out of memory on STM32 w/ 64k SRAM.
I didn't expect anything less from this patch. I tested it on a "simulated" environment before starting to work on eLua, back when I was checking if it was at all feasible to run Lua on system limited to 64k of RAM and even less. And it performed very good. There is of course a performance penalty, but I'd say that in practice the EGC is extremely useful for thte vaste majority of applications. After all, it's quite unlikely that someone would choose eLua to run computationally intensive programs that would suffer from the performance impact :)
I agree. Does the performance hit only show up during a GC (emergency or no)? I've not clocked any of this yet.
In practice I would say since we have a fixed amount of memory, it's really undesirable to fail simply because a garbage collection event wasn't called in time. The other side is that if the penalty is only at GC time, people could disable collection during time-critical operations. I haven't taken a deep look to understand how every part of the patch works yet, but I see that it does provide a configurable of a memory limit. Maybe another interesting tunable might be how many GC steps to take when an emergency GC is called (i.e.: just enough for the allocation pending, full gc, or something else?) I'm also still curious about the idea of running GC in fixed timesteps,
In the interests of pragmatism, I don't think I'd pursue anything more detailed here unless I run up against some situation where it doesn't work as desired. I think, overall, a default of sane incremental collection (maybe with the GCPAUSE set to 110) and a backstop emergency GC should be a good solution for most cases.