Re: Incremental garbage collection coming to Lua soon?

[Mark Hamburg <mhamburg@...>]

If going this route, I would recommend only counting references from tables
and closures and avoid counting references from the stack together with a
zero-ref-count list that lists objects that either have no references or are
only referenced from the stack. Dealing with refcounts while storing to
tables is probably a relatively small hit and the stack is already scannable
for the existing GC.

This also has the benefit of being something that could be done in 5.0.5 as
a precursor to an incremental GC in 5.1.

I say all this without having looked closely at the GC code though I was
pleasantly impressed today at how easy it was to replace the standard
setjmp/longjmp exception mechanism with something based on Cocoa's exception
system (which is also setjmp/longjmp based but generally more complicated).

Mark

on 7/30/03 3:40 PM, David Jeske at jeske@chat.net wrote:

> Luiz -
> 
> There are some interesting lessons to learn from the work Python has
> done on GC.
> 
> Historically Python was reference counted, making object deallocation
> time very predictable -- although not collecting cycles. A few
> versions ago they introduced a generational cycle finder. In the
> latest version this cycle finder is enabled by default.
> 
> The interseting things about these scheme are:
> - ref-counting will immediately free non-cyclic stuff
> - it's easy to make the cycle-finder incremental, since
>  the refcounting is your write barrier
> - Python's implemention uses the fact that only collection
>  types are involved in cycles. The cycle finder does not have
>  to scan any non-collection types, eliminating lots of
>  objects from the sweep. In Lua, the only objects which can
>  be involved in cycles are tables.
> - the overhead of the cycle finder is quite low (5-10% in
>  some benchmarks)
> 
> Of course reference counting slows down the speed of assignment
> instructions. However, as has been pointed out before, if we wanted
> code to be 'really' fast it would be in C.
> 
> Anyhow... I hope this is a useful contribution to your thinking about
> incremental collection schemes. I am interested in hearing your
> throughts when you're ready to share them.