Re: Can userdate have references to lua objects?

[RLake@...]

> You may not like how Lua works in that case, but that does not make it
> a memory leak. As long as both objects are reacheable from the program
> (root set), "fail" to collect them cannot be a leak.

Yes, but. (And please don't take this personally -- I'm trying to help :) I
accept that "memory leak" is a loaded term -- but see the definition from
the Memory Management Glossary below.

There is a difference between "reachable" and "live". Consider the
following:

function foo()
  local a = {}
  for i = 1, 1000000 do a[i] = i end
  local a
  -- whatever
end

The first "a" is on the stack; it is "reachable from the root set". But
there is no mechanism in the language for accessing it (I don't think that
even the debug library will give it to you.) So is it reachable? I would
say "no"; the semantics of the language make it "not live", once we enter
the code which starts "--whatever". (This is, of course, not true of the
semantics of the VM, but the VM is an implementation detail. :)

Similarly, if t is a weak-keyed table, and there is no reference left to a
key or to its associated value, that value is not "live", except through
iteration over the weak-keyed table. Now if I never iterate over weak-keyed
tables, or I make it impossible to iterate over them, then the value is not
referenceable. (I can easily enough create a class of weak-keyed tables
which are not iteratable, by redefining next at initialisation.)

So "reachable" is a superset of "live", since the root set contains things
(dead stack objects, for example) which are not live.

I think it is legitimate to say that never garbage collecting an
unreferenceable object is a memory-leak, on the "if it looks like a duck
and quacks like a duck then it might as well be a duck" principle. Memory
expands uncontrollably, and I cannot get at the objects which are occupying
memory. So it "might as well be a memory leak". :)

Or to put it another way, if I'm writing a full description of weak-keyed
tables, I would add the caveat "If a weak key/value is reachable from its
strong value/key, then neither object will be garbage collected." This is
not much different from the caveats in reference-counted systems ("if two
objects refer to each other, neither will be garbage collected") or for
that matter explicit allocation systems ("if you lose a pointer to an
object, you will never be able to free it"), both of which are
traditionally considered "memory leaks".

-------------------------

>From the Memory Management Glossary:
<http://www.memorymanagement.org/glossary/m.html#memory.leak>

memory leak, space-leak (also known as leak, space leak)

  A memory leak is where allocated memory(2) is not freed although it is
never used again.

  In manual memory management, this usually occurs because objects become
unreachable without being freed.

  In tracing garbage collection, this happens when objects are reachable
but not live.

  In reference counting, this happens when objects are referenced but not
live. (Such objects may or may not be reachable.)

  Repeated memory leaks cause the memory usage of a process to grow without
bound.

------------------------

R.