Re: Memory leak?

["alex.mania@..." <alex.mania@...>]

>To make a bit more clear, in the following example, is what the string
>says correct?
>
>foo = {}
>bar = {"This string is never cleaned up."};
>foo[bar] = nil;
>bar = nil;
>while(true) do end

>From my understanding, yes (Mike Pall?)
I believe this would be sufficient too:

  bar = "This string is never cleaned up."
  foo[bar] = nil
  bar = nil
  while(true) do end

>Great :) At least there's a way around the problem. Building on the
>above, I have found that "foo.bar = nil" will consistently and
>repeatedly reclaim the memory used by "remembered" keys. Apparently,
>when assigning it nil instead of some other value, the "bar" key is
>reclaimed immediately as well, which allows the same trick to work
>again and again.
>
>Does that mean that Alex's trick above will only work sometimes,
>depending on what keys are already in the hash part?
Exactly, it'll only work if a resize of the hash table is required. When it's
resizing the hash table, it resizes the array component at the same time. Note,
if a table is used exclusively as an array then any setting of its hash table
will require a resize (that's why the example works). (I didn't realize this at
the time though =)

>But I do think there needs to be some way to affect this. I'm not
>saying this behaviour should be changed at the cost of certain
>features, or at the cost of efficiency (please don't!). But at the
>very least clean it up when the garbage collector is explicitly called
>:P and maybe add something to the list of allowed arguments to
>collectgarbage() which does just that. Say, collectgarbage("keys"), or
>something.
Hmm, I guess it would involve setting a flag every time "next" is called, and
clearing it whenever a new key is created. When the table gets marked during a
garbage collector cycle, resize vectors if they're disproportionately large.
Wouldn't slow down tables measurably I don't think.. nor the gc (whenever a table
is marked, the incremental gc takes in to account how expensive the mark
operation was... could take any resizing operations in to account).

Good luck finding a spare bit in the Table structure though =). Also, it may
produce intermittent errors in "next" in programs that currently get away with
modifying the table. (They shouldn't, but you still can get away with it on
occasion). There's also the question of how many programs would actually benefit
from it.

- Alex