Making `t[1]=1` does not help. Btw let me provide some more information of
my application
My Application implements the business logic. It is connected to a PBX
Server over the TCP socket. When a call lands on PBX Server, it sends an
event to my application and my application then instructs back to PBX
Server what to do next.
My Application has 4 event threads and 10 worker threads. We have used
thread library from torch framework https://github.com/torch/threads. In
every thread, I have put the collectgarbage(count). I observed that it
returns in range of 1-2 MB. I mean whenever it reaches to 2 MB or so, next
time it returns 1 MB. So IMO whatever lua tables we have used, they are
being collected.
I see lot of anon blocks with 65MB size when I took the pmap of luajit
process. I also observed that when I increase number of worker threads, RES
Memory increases too on application startup. It is coming out be 7 MB per
thread.
--
BR,
Atul
On 2 August 2018 at 03:53, Javier Guerra Giraldez <javier@xxxxxxxxxxx>
wrote:
On 1 August 2018 at 18:18, Atul Thosar <atulthosar@xxxxxxxxx> wrote:
Thanks a lot for your response and apologize delay from my side forcritically. I
responding back.
Not sure I understand all, but I started looking into my code
have extracted minimal version of my application and trying to check howXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
collectgarbage("collect") may help. Here is the program
-- Program Starts
t = {}
for i = 1, 5000000 do
t[i] = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end
print (collectgarbage("count"))
the table `t` has 5 million elements, but all of them hold the same
string. since strings are immutable, there's no point in storing 5
million copies of it, so they are all references to the same string
object. the memory used is the table itself. when you clear it, it's
not immediately shrunk. try assigning a single value after clearing
it, like `t[1]=1`. this might trigger the downsizing of the table.
also, when the table is cleared, the string object can't be discarded.
Since it's a constant in your code, the bytecode holds one more
reference to it, so it's almost permanent. (unless you release the
code chunk itself).
finally, when you remove the reference to the table (with the
`t=nil`), what you're releasing is the table itself, not the string
object.
