[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: GC: strange behavior
- From: Rici Lake <lua@...>
- Date: Sat, 21 Aug 2004 11:54:27 -0500
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