Re: Updating to 5.1w5: My change list

[Mark Hamburg <mhamburg@...>]

on 3/17/05 5:34 PM, Mike Pall at mikelu-0503@mike.de wrote:

> Umm, but luaC_step will only ever call back another function inside
> GCTM and this one _does_ disable hooks (both in the original core and
> with the RVM patch). And GCTM suspends the GC, too, to avoid recursive
> calls to luaC_step. I.e. infinite recursion is already taken care of.
> 
> I can only infer that you see a memory leak or infinite recursion,
> but I fail to see how your change improves the situation. Care to explain?
> 
> Oh and completely disabling the GC inside hooks is at least problematic.

Okay. I see the code in question now that is supposed to prevent recursion
within __gc metamethods. Mucking with the threshold seems a bit fragile to
me as a way to achieve this. For example, a call to collectgarbage( "step",
n ) will slam right over the top of this. But it probably works in practice.

The recursions I was seeing in older releases weren't I believe infinite but
they were deep enough to blow out the stack. Or they may have been infinite
and I just didn't dig deeply enough once I found the point of recursion.

So, what I was endeavoring to do was to disable the incremental collector
inside of __gc metamethods and the easiest point to catch that seemed to be
from the fact that those calls disable hook routines.

On a related note from looking at the code, I have to say that LUA_GCSTEP
doesn't do what I would have thought it would have done. I would have
expected it to run things forward as if a certain amount of memory had been
allocated -- i.e., as if totalbytes had been driven up. Or alternatively, it
could have lowered the threshold by the step amount. Instead, it sets the
threshold based on the step. Doesn't this mean that calls to "step"
essentially throw the garbage collector into fully-active mode since the
threshold will now be less than totalbytes?

Mark