Re: Re : luachip

[Mark Hamburg <mhamburg@...>]

Reference counting can limit the recovery cost to the maximum object size as
well by using incremental freeing. I guess it might be easier to make it
even more incremental since the objects being traversed necessarily won't be
being changed.

Naïve reference counting does not need to worry about the stack size. On the
other hand, naïve reference counting pays a much bigger cost for stack
operations. Using a zero-count table plus stack scanning gets one back into
having stack size be a factor in pause time.

I'm not sure how reference counting deals with weak tables. We know it
doesn't deal with cycles.

Mark

on 8/14/04 7:29 AM, John Belmonte at john@neggie.net wrote:

> Roberto wrote:
>>> Are there issues with Lua 5.1 for real time work?
>> 
>> Its atomic section must traverse all stacks and all weak tables of the
>> program. If you have lots of them (and they are big) the atomic step may
>> take a while to complete.
>> 
>> Moreover, each atomic step does not stop during a traversal. So, if you
>> have one really big table in your program, its traversal may take a
>> while too.
> 
> Compared to non-incremental mark-and-sweep, it's much easier to control
> your application's maximum table size than its total number of objects.
> Throwing reference counting into the comparison as well, we have:
> 
>  method of garbage collection  worst case GC duration
>  ----------------------------  ----------------------
>  mark-and-sweep                O(num objects)
>  reference counting            O(num unreferenced objects + X)
>  incremental mark-and-sweep    O(max table size + X)
> 
> where X is (stack size + num weak tables).  Does that look right?
> 
> -John