RE: garbage collection thoughts... again?!

["Nick Trout" <nick@...>]

> From: Thatcher Ulrich [mailto:tu@tulrich.com] 
> On Thu, 29 May 2003, Peter Hill wrote:
> >
> > For example: should the GC be completely transparent to the 
> coder (a 
> >
> > Despite the recent non-shrinking-table oddity (the 
> programmer having 
> 
> Yes, I think this is probably the best argument against 
> ref-counting for Lua.  One of the big advantages of 
> ref-counting is the predictability, which means programmers 
> may tend to rely on its behavior, making it impossible to 
> change the GC implementation without breaking programs.  
> Likewise ref-counting does sometimes require some explicit 
> management, which further ties programs to the implementation.

This was mentioned on the list a couple of weeks ago. Programmers should
not be relying on the way GC works to manage their data. If it is
important the way things are collected then the application should be
constructed in such way that it is independent of GC.

Wrt to Python I don't think Python came with a standard cyclic garbage
collector until version 2.0. There were several libraries before this
point to find cycles. I never paid any attention to cycles as I never
needed to - so I might have had a lot of leaked islands but I had lovely
VM. Without having studied it in detail it looks like you have to tell
Python which objects are grouped together so that it can work out where
cycles are, e.g.
http://www.python.org/dev/doc/devel/api/supporting-cycle-detection.html

I'm not sure what Python does with these containers; perhaps they have
write barriers and they use mark and sweep?! This doesn't look very
transparent, could be erroneous, and just complicates the binding
process. One of the reasons I moved away from Python towards Lua was
that you don't have to deal with reference counting in the Lua API -
which caused several annoying bugs when I first started using it. Lua is
much simpler and it looks like Python is more complicated than when I
left it.

I haven't read as much GC material as you, the following is my
buzzwordtastic understanding of Lua's direction and what I remember of
past GC discussions. Incremental GC on its own could be quite
inefficient, i.e. cycles will be wasted passing over the same data when
it drifts back into the grey area. But, incremental with generational
should counter this problem. I agree that this solution is non-trivial
but the Lua authors have come up with the goods in the past and have
made good optimisations and simplifications in the past (eg. Global
namespace as generic table, environments), and the API is pretty easy.
GC is transparent to the user and does exactly what it should: collects
unreachable objects. Ref counting on its own is undoubtably simpler, but
how do you deal with islands; are you not just back to the problem of
how you distribute processing of a mark and sweep like algorithm.
Superficially it looks like Python divides objects into groups and uses
writebarriers and some higher collection algorithm to collect the
containers.

Your solution for C++ objects relies on the skill of programmers to
optimise dependencies. This should be transparent to script users and is
indeed one of the reasons why people use such languages. Commonly, the
users of embedded Lua may be junior or "lesser" programmers than the
application programmers and unaware of cycles they may create and would
not understand weak links.

Perhaps there is a different solution besides IGC or RC. This discussion
has been had a few times and IGC seems to the frequent winner - in fact
I think I remember mails where you were adamant it was the correct
solution. I'm sure Thatcher will report any findings from the GC list.
:-) (P.S. I like "See through"). 

Regards,
Nick