lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Thanks for your reply.
I'm feeling rather easy now.

> This is most probably not a bug. In fact most of the consequences of
> changing the GC parameters are unspecified. The manual makes it pretty
> clear that you are on your own if you want to fine tune the GC.

I guess that you mentioned is based on this part of Lua reference manual.
 > The step "size" is controlled by arg (larger values mean more steps) 
 > in a non-specified way

It says the amount of GC processing is not defined. It's ok. But it doesn't 
say that this function may never returns, or cause "undefined behavior".

If I looked into the problem(1) ("freezing problem") with VC++ debugger, 
it doesn't seems to be the situation that it will take long time because 
too small amount is processed in one step. But rather, GC runs more than 
one cycle. It doesn't stop even when it collects all garbages on the VM.

I don't think this behavior is "feature". If then, the document should warn that
collectgarbage("step", n) may never return when you change GC parameters.


> For example, everything works here on linux, and the effect of using a
> step size argument is platform dependent, as the manual says. My guess
> is that using step size 0 is too small for your runtime.

Lua's GC code doesn't look different with platforms, though I should not 
rely on that.

Then I tested the behavior on ubuntu (on VMWare, using LuaBinaries linux 32bit).
It is the result. The last call to collectgarbage("step",0) never returns.
I waited 40 minutes and it doesn't respond.

-------------
hammmm@vmubuntu:~$ ./lua5.1
Lua 5.1.3  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> collectgarbage("setpause",100)
> collectgarbage("setstepmul",2000)
> collectgarbage("stop")
> collectgarbage("step",0)

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

Is that apparently different on your linux box?


>My guess is that using step size 0 is too small for your runtime.

I read on PIL 2nd ed (page 298) as the value of zero means "small step", 
and looping collectgarbage("step",0) with for or while statement is an 
good idea, so I wanted to go that way.

Then I changed the value and experimented.
Again, the last collectgarbage("step",10) doesn't return control 
to the prompt.

-------------
hammmm@vmubuntu:~$ ./lua5.1
Lua 5.1.3  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> collectgarbage("setpause",100)
> collectgarbage("setstepmul",2000)
> collectgarbage("step",10)

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

This time I omitted GC "stop" because it will not affect the result.
On the other hand, "setpause" and "setstepmul" apparently affect the 
behavior of "step".


And, as of problem (2), on ubuntu,

-------------
hammmm@vmubuntu:~$ ./lua5.1 test.lua
=====================================
collectgarbage("count") * 1024 = 22082 bytes
>>>>>>>>> create static data 
collectgarbage("count") * 1024 = 34081 bytes
>>>>>>>>> GC step 
step :  1       38564   bytes   diff:   4483    bytes
step :  2       43637   bytes   diff:   5073    bytes
step :  3       48098   bytes   diff:   4461    bytes   #GC mark phase
step :  4       52559   bytes   diff:   4461    bytes
step :  5       56999   bytes   diff:   4440    bytes
step :  6       61185   bytes   diff:   4186    bytes
step :  7       61036   bytes   diff:   -149    bytes
step :  8       49657   bytes   diff:   -11379  bytes   #GC sweep phase
step :  9       45644   bytes   diff:   -4013   bytes
step :  10      49926   bytes   diff:   4282    bytes  <-------- GC cycle end flag can't be catched around here
step :  11      54388   bytes   diff:   4462    bytes
step :  12      58850   bytes   diff:   4462    bytes
step :  13      63291   bytes   diff:   4441    bytes
step :  14      67753   bytes   diff:   4462    bytes
step :  15      72194   bytes   diff:   4441    bytes
step :  16      76635   bytes   diff:   4441    bytes
step :  17      80886   bytes   diff:   4251    bytes
step :  18      82301   bytes   diff:   1415    bytes
step :  19      70923   bytes   diff:   -11378  bytes
step :  20      59547   bytes   diff:   -11376  bytes
step :  21      49931   bytes   diff:   -9616   bytes
step :  22      54394   bytes   diff:   4463    bytes
step :  23      35599   bytes   diff:   -18795  bytes
step :  24      36543   bytes   diff:   944     bytes
step :  25      41004   bytes   diff:   4461    bytes
cycle end. step count:  25
step :  26      45466   bytes   diff:   4462    bytes
step :  27      49928   bytes   diff:   4462    bytes
step :  28      54369   bytes   diff:   4441    bytes
step :  29      58831   bytes   diff:   4462    bytes
step :  30      63272   bytes   diff:   4441    bytes
step :  31      67713   bytes   diff:   4441    bytes
step :  32      72154   bytes   diff:   4441    bytes
step :  33      76595   bytes   diff:   4441    bytes
step :  34      80805   bytes   diff:   4210    bytes
step :  35      82301   bytes   diff:   1496    bytes
step :  36      70923   bytes   diff:   -11378  bytes
step :  37      59547   bytes   diff:   -11376  bytes
step :  38      49931   bytes   diff:   -9616   bytes
step :  39      54394   bytes   diff:   4463    bytes
step :  40      35599   bytes   diff:   -18795  bytes
step :  41      36543   bytes   diff:   944     bytes
step :  42      41004   bytes   diff:   4461    bytes
cycle end. step count:  18
step :  43      45485   bytes   diff:   4481    bytes
step :  44      49947   bytes   diff:   4462    bytes
step :  45      54409   bytes   diff:   4462    bytes
step :  46      58850   bytes   diff:   4441    bytes
step :  47      63312   bytes   diff:   4462    bytes
step :  48      67753   bytes   diff:   4441    bytes
step :  49      72194   bytes   diff:   4441    bytes
step :  50      76635   bytes   diff:   4441    bytes
collectgarbage("count") * 1024 = 76676 bytes
collectgarbage("count") * 1024 = 32079 bytes
=====================================
-------------


> I suggest that you avoid using the word "bug" for "I can't understand
> what's happening" next time. I think you would have gained much more
> help from the list if you did.

Thanks for your suggestion. I'll do that next time.


Regards,
Makoto Hamanaka <naraxx800@yahoo.co.jp>