RE: Can userdate have references to lua objects?

["Bilyk, Alex" <ABilyk@...>]

 -----Original Message-----
From: 	RLake@oxfam.org.uk [mailto:RLake@oxfam.org.uk] 
Sent:	Monday, May 12, 2003 9:52 AM
To:	Multiple recipients of list
Subject:	Re: Can userdate have references to lua objects?

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". :)


Yesterday I was playing with my Lua thread library and noticed that the following script will lead to a large amount of memory retained indefinitely by the application unless manually freed.

--------------BEGIN-------------------------------------------------------------------------

N = 100000
t = {}

print(gcinfo())

for i =1,N do -- fill up a huge table
	t[i] = i
end

print(gcinfo())

for i =1,N do -- empty the table
	t[i] = nil
end
collectgarbage () 

-- NOTE! At this point the table is empty but has retained all the memory needed to store N+ entries.

----------------------------------------------------------------------------
print(gcinfo())

t = nil -- NOTE! This is effectively a manual de-allocation. 
collectgarbage ()

print(gcinfo())

------------END----------------------------------------------------------------

This means that tables in Lua can only grow without ever shrinking back. Of course every time we add to containers we seem to always think of the growing strategies for them. But shrinking containers back to a more realistic size seems to be less of a concern. I wonder why? Sure, if I am actively adding to a container the growth strategy is very important. What if I am actively removing from it? Is this somehow less important or less frequently used case? 

We have this big project and use super-fast allocators for small objects in C++. Up until recently the allocator class only had a growth strategy. At some point we had discovered that the application consumed a lot more memory than needed because the allocator class didn't know how to shrink its available memory pool back. I think the example above illustrates the same thing with Lua. The assumption has obviously been made that if the table had at any time N entries is has to stay as large or larger to accommodate N+<delta> regardless of its current size. I wish the table size would have gone back as it becomes less populated according to some strategy - "A plan is better than no plan.", as classic said.

I am only posting it here as I consider this also a memory leak *of sorts*, is it not?

Does this make sense?

Alex 

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

>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.


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

R.