[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Memory leak?
- From: "Mark Meijer" <meijer78@...>
- Date: Fri, 1 Feb 2008 01:55:30 +0100
Btw... I do hope I haven't offended anyone with this... I know I can
be a bit blunt sometimes, but I never mean any disrespect.
I felt I needed to get that off my chest. FWIW
Sincerely,
Mark
On 31/01/2008, Mark Meijer <meijer78@gmail.com> wrote:
> 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
> >
>