Re: how can i manage lua memory

[Fabien <fleutot+lua@...>]

As explained in other answers, the notion of "table size" is intrinsically bogus, when you try to take its referenced objects into account: objects can be referenced in several tables, there can be loops in the reference graph, etc.

However, for leak detections, bogus measures are often good enough. I usually write a piece of code implementing this measure:

S(table) = 1 + sum of the sizes of all keys and values, checking that multiply referenced objects appear only once. As an important side effect, it prevents infinite loops on cyclic graphs.

S(number, boolean) = 1

S(string) = 1 + #string

S(nil) = 0

S(function) = 1 + sum of the sizes of the upvalues.

In practice, I don't bother measuring metatables or threads. It might or might not be good enough for your programs. Same for userdata, you might have to define a fancier measure for them, depending on the way you use them.

Then I add a table, suspected objects -> last known bogo-size. I regularly check whether sizes change, and log those size changes.  Once I've put enough objects under surveillance the leak is generally quite easy to find. 

Depending on your programs, size change logs might be too verbose: adapt you definition of "changing size", e.g. by admitting a deadband (don't consider a size as modified until it changed more than XX%, compared to the original measure).

Sorry, no code to share, but you can quickly write and adapt your version.

-- Fabien.