Re: Our change list for Lua 5.1work2

["Adam D. Moss" <adam@...>]

Roberto Ierusalimschy wrote:
> > However, it's pretty hard for users to tune magic numbers like this
> > without knowing at least a little about the effect they have, so they
> > will know the point at which their program's demands are likely to cause
> > the need for a re-tuning session.
>
> Well, this number has a reasonably meaning: it is quite near your 'speed
> vs. peak memory usage'. The larger the number, the less intensive is the
> GC; less time spent collecting garbage, more garbage accumulating. So,
> you should use the larger number that your memory can support. (That is,
> larger numbers improve performance up to the point where memory problems
> put the performance down again.)

Thanks.

Incidentally, is it possible (without abusing such a magic number
by setting it to zero or such) to be in a situation where the app
generates short-lived objects faster than the GC is inclined
to reap them?  I'd expect space tradeoffs to add/remove a
constant or linearly-proportional space overhead, but a pattern
where (for example!) the app creates 500 dead objects a second while
the GC has been accidentally space/time tuned to only reap up to 400
objects in the same time, will cause an ever-expanding death-spiral
I think.

I can think of some incremental GC aggressiveness tuning heuristics
that sound in theory like they should generally do the right thing
automatically, but they are probably the sorts of naive things
that would only be thought of by someone who has never implemented
a GC system at all. :)  Or Lua 5.1 already does them, of course!

Sounds like something fun for me to try to look into in a few months.
Before then, I'll likely do another couple of rounds of testing
with various magic number values.

Regards,
--Adam