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 12:42 PM
To:	Multiple recipients of list
Subject:	RE: Can userdate have references to lua objects?


Tables only shrink when they are about to grow :)
Aha! Somewhat counter-intuitive but I can live with this. I didn't mean to suggest for the GC to shrink tables. It was more of a general observation case. 

Most of the time, this is ok, because tables either grow constantly and are
deleted, or grow and shrink randomly. It will only create a problem in the
case where a table is grown to a massive size, then most of the elements
are deleted, and then no new elements are added. If you are doing that, you
should probably copy the table after deleting the elements.
Got it.

The Lua garbage collector cannot shrink tables, because this would affect
I didn't mean to suggest this. I just thought it would have been more logical to shrink the table as it loses entries. But then I am not familiar with all intricacies of Lua table management.

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

This is a funny definition. If I do "a = {}" and never use "a" again, I have a memory leak... So memory leaks are non-computable.
-- Roberto
I would actually agree that this is a memory leak but this would certainly be no Lua's fault, IMHO. If one allocated a block, used it and forgot about it for the rest of the application session, the memory is wasted. I call these kind of leaks "run-time" leaks, meaning that although application will reclaim the memory upon exit it is effectively wasting it during run-time. I think under most modern workstation OSes application can not leak memory as even if it did the OS would free it anyway upon application process de-allocation. This may not be true for other kinds of resources however. But, "run-time" memory leaks still present a problem as a vital resource gets wasted. Just a subjective view of mine, really.

Thanks,
Alex