Re: Memory leak?

["Mark Meijer" <meijer78@...>]

Come to think of it, it should probably be a function called on
individual tables, rather than one function which does all tables,
which might not be practical.

I don't know jack all about Lua internals, but I've taken a look at
ltable.c and I found the resize function, as well as a couple of
places that trigger it, directly or indirectly (in table.c but also
for example in lvm.c at the opcode that sets table entries). But as I
don't know half of what's going on in there, I wouldn't feel
comfortable exposing anything like that to Lua or the C API, even if I
did know how to do that neatly.



On 30/01/2008, Mark Meijer <meijer78@gmail.com> wrote:
> On 30/01/2008, alex.mania@iinet.net.au <alex.mania@iinet.net.au> wrote:
> > I'm guessing you saw in the reply that the GC can collect the keys =). So the
> > loss is only minor - it's only the 28 (or 32, depending on kludge factor) bytes
> > for a Node. The key can still be collected, just not the node.
>
> Yeah :) Thanks.
>
>
> > Yes, that would work. I can't see it being implemented though for the number of
> > bugs it could introduce in seemingly good code. Just think, a function that'd
> > break any pairs() loop it's inside of, no matter how nested the call to this
> > function is. And not just break the ordering, but make the loop throw an error -
> > something a normal loop would never do.
>
> Your point is well taken, if only to dismiss the suggestion I did that
> at least collectgarbage("collect") should clean up the remaining nodes
> (in addition to the full collection cycle). I.e. perhaps it shouldn't,
> for the reason you mention.
>
> But I don't think anyone is currently calling collectgarbage("keys")
> anywhere, much less in a loop involving next(), since "keys" is not a
> valid argument to collectgarbage :) ...(or whatever would be a
> suitable name for it, if not "keys").
>
> Though I admittedly don't know the result of calling collectgarbage
> with an invalid argument, it's most likely either strictly invalid and
> returns nothing (or error), or the behaviour is "undefined". Either
> way, I'd have to argue that it is perfectly safe to add this extra
> option without breaking any existing code.
>
> If that still makes people uncomfortable, then it could just as well
> be made into a separate function with a different name. And if that
> still makes people uncomfortable, then - dangnabbit :P - add it to the
> Lua C API or something, lol...
>
> Even if nobody will ever need it for all eternity until the end of
> human-kind, one day an alien civilization is going to dig up Lua from
> our remains and say "jeesh, it held on to memory even when no longer
> needed, and there was no way to reclaim it?"
>
> Heheh... Ok jokes aside, the principle being: It is my humble opinion
> that there should be a way to reclaim those nodes without having to
> dig into Lua internals and modify and recompile it. :)
>
> Cheers,
> Mark
>