[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Boxed userdata and garbage collector
- From: "Juris Kalnins" <juris@...>
- Date: Mon, 06 Sep 2010 12:22:40 +0300
On Sun, 05 Sep 2010 20:00:46 +0300, Mark Hamburg <firstname.lastname@example.org> wrote:
On Sep 3, 2010, at 1:29 PM, Roberto Ierusalimschy wrote:
In Lua 5.2, on the other hand, the 'x' in collectgarbage( 'step', x )
will correspond exactly to the work the collector does when allocating
1KB of memory, so it should not be that tricky to set it.
[Assuming it's typo and "x kB" was meant]
The approach of calling 'step' when allocating the image (with an
appropriate definition for 'step') seems to be conceptually equivalent
to telling Lua about extra space in use which should drive the GC
forward. What's lost is the ability to say, "but I manually released
that space, so we can turn the pressure back down".
Oh, but there's no "pressure". Quite the opposite, the more memory you
have allocated, the more GC is relaxing. (See the definition
of stddebt in lgc.c)
Lua GC measures the amount of work it has to do in an abstract
units of work (GCthisCOST and GCthatCOST), and does about
gcstepmul units of work per one step. Every kilobyte you allocate
will buy you gcstepmul units of work from GC.
Cost of sweeping (freeing) data does not depend on it's size.
When GC finishes one cycle, it goes on a vacation, determined
by the gcpause value.
collectgarbage( 'step', x ) will run step x times, but not
beyond the end of current cycle. If it was near the end, it will
do just a little, and enter pause.
Nothing it all that logic depends on the size of allocated data,
except for the length of the pause.