[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: bug of GC "step"
- From: Makoto Hamanaka <naraxx800@...>
- Date: Thu, 03 Jul 2008 00:36:38 +0900
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>
