Re: GC: strange behavior

[Rici Lake <lua@...>]

On 21-Aug-04, at 11:39 AM, Edgar Toernig wrote:

> It has very little to do with the garbage collector.  It's
> a feature of malloc/free.

Absolutely (and I agree with the rest of the comment). Also note that
while the memory usage is displayed by top, actual RAM is not being
used. The unused pages will (probably) be swapped out to VM backing
storage, and will not occupy RAM again until they are needed.

In Case 3, where you are allocating strings, you are running into
a feature of Lua, I think. Strings are interned into a string table
which has its own hash vector. collectgarbage() gets rid of the 
unreferenced
strings, but does not shrink the intern table's hash vector to a minimum
size, rather it halves the allocation if that seems reasonable. 
Consequently,
successive calls to collectgarbage() will show the intern hash table
slowly being halved down to its original size.

In a normal application, it is probably reasonable for Lua to assume 
that
the string table will return to something approaching its high water 
mark,
so the behaviour, like that of malloc, can be considered an 
optimisation for
the common case.

> t = {}
> for i = 1, 3e6 do t[i .. ""] = i end
> print(gcinfo())
200314  358304
> t=nil
> print(gcinfo())
8205    16410
> collectgarbage()
> print(gcinfo())
4109    8218
> collectgarbage()
> print(gcinfo())
2061    4122
> collectgarbage()
> print(gcinfo())
1037    2074
> collectgarbage()
> print(gcinfo())
525     1050
> collectgarbage()
> print(gcinfo())
269     538
> collectgarbage()
> print(gcinfo())
141     282
> collectgarbage()
> print(gcinfo())
77      154
> collectgarbage()
> print(gcinfo())
45      90
> collectgarbage()
> print(gcinfo())
29      58
> collectgarbage()
> print(gcinfo())
21      42
> collectgarbage()
> print(gcinfo())
17      34
> collectgarbage()
> print(gcinfo())
15      30
> collectgarbage()
> print(gcinfo())
15      30