Re: Garbage collection

["tom7ca" <tmb-yahoo-egroups@...>]

> Well, in the specific case of game development, based on my
experience
> and discussions with other game developers, I think you're giving
bad
> and unfounded advice here.

I'm not aware of having given advice, let alone "bad and
unfounded advice.  I don't really care what you do in your
programs.  All I pointed out is that reference counting
is not real-time, while a real-time garbage collector
(by definition) is.  It's actually worse than that: anything 
that calls malloc or free fails to be real-time (or even soft 
real-time) because the C allocator makes no guarantees about 
latency.

> If you have real-world experience to the
> contrary, I'm all ears.

You have probably had the same experience but not thought
about it: programs that inexplicably pause for several seconds
after you Quit them, games that take forever to go from one
level to the next, games that crash after replaying the same
level several times, games that stutter, games that spew out pages
of messages about reference counts not being zero, etc.
Those are often consequences of various reference
counting schemes, and they are completely avoidable.

And that isn't even counting the less tangible consequences
of reference counting: obscure design decisions in an effort
to avoid circular references, unecessarily
high hardware requirements to make up for the overhead, etc.

> On the other hand, the average game developer might be more likely
to
> adopt a reference-counting approach, for two main reasons 1) it's
> straightforward

I think the sorry reliability of gaming software is actually a good 
illustration that this is not "straightforward" at all for game
developers and that game developers would do well to re-think
their approach.

> 2) it's more
> deterministic, so bugs in the GC [presumably, you mean 
> reference counting] tend to be easier to find and fix.

That may or may not be true for C code.  But using
reference counting for Lua objects introduces the possibility
of leaks where previously you had reliable and correct
memory management.  That does not seem like a step forward.

Overall, my point is this.  Allowing for reference counting
in Lua just constrains the implementation further, and it
doesn't solve the real-time allocation problem.  And reference
counting is certainly not a good default allocation strategy
for Lua because it's inefficient and a pain to use from a C API.
Reference counting is probably the worst part of, for example,
the Python implementation.  Hard as it may be, if Lua is
to be used for (soft) real-time problems, I think it's better
to solve the problem correctly: fix the incremental collector
or implement a hard real-time collector.

Tom.