[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: bug of GC "step"
- From: Makoto Hamanaka <naraxx800@...>
- Date: Fri, 04 Jul 2008 12:02:32 +0900
Thanks also for providing more information, Mauro.
> I wonder whether it makes any sense to allow for gcpause<100. Also,
> since this is integer division, threshold may be well under estimate
> (and totalbytes) even for gcpause==100. Anyway, maybe a mention of
> this in the manual could be nice, even if not strictly necessary.
As you said, it looks like gcpause<100 doesn't make much sense,
under the situation that there's no other way than GC to release memory.
And currently it is so.
>From my reading of GC code, that g->estimate is the g->totalbytes just before
sweeping phase, minus released memory on sweeping phase.
So currently, there's no possibility of g->totalbytes < g->estimate on
the end of GC cycle. Whereas g->totalbytes can grow.
> > moreover, putting this line after lgc.c:631 removes the freeze:
> > if (g->totalbytes >= g->GCthreshold) g->GCthreshold = g->totalbytes+1;
> > and since luaC_step is only used by lua_gc it has little consequences.
> > But it would seem better to change the setthreshold macro.
I think it will work on almost all cases.
Though that change of code will affect the GC behavior, from "GC is
ready now" to "GC is ready if one byte of memory is newly allocated".
With automatic GC enabled, just one call to luaC_step can be missed per
GC cycle, as I guess.