Re: The Lua 5.1(work) GC

[Mark Hamburg <mhamburg@...>]

The benefit of incremental GC is eliminating (or significantly reducing)
pause times. It comes at the price of reduced overall efficiency because of
increased book keeping and possibly increased memory thrashing.

Reference counting by comparison is very good at avoiding pauses and very
good at keeping memory and resource usage down, but comes at the cost of
lots of book keeping and an inability to collect cycles. (If you worry about
the pause times for freeing large structures, you can do that
incrementally.)

I'm just getting ready to look at 5.1 (after I clean up some uses of .n).
One thing I'm curious about is whether it does anything to reduce the need
to lock the Lua state when manipulating the stack. Reducing the number of
cases that need to acquire the global lock would be useful when running Lua
in a multi-threaded environment with shared Lua data structures.

Mark

on 5/25/04 10:34 AM, Roberto Ierusalimschy at roberto@inf.puc-rio.br wrote:

>> Inspired by a paper referenced in that post, this is what I wanted:
>> "just specify the amount of wasted memory to be tolerated as a
>> percentage of in-use memory, with higher tolerance translating to lower
>> GC overhead".
> 
> The problem here is how to compute the speed of an incremental
> collector given those parameters. Suggestions are wellcome.
> 
> 
>> Incremental GC (the subject of this thread) is there to reduce worst
>> case memory and CPU usage.
> 
> I'm not sure about that. It seems much easier to ensure worst-case
> memory with a mark-and-sweep collector. CPU usage (average) also seems
> to increase with an incremental GC, due to higher administrative
> overhead.
> 
> -- Roberto