Re: GC order

["Michael T. Richter" <mtr1966@...>]

> An incremental garbage collection routine (with generational
> optimisation?! ;-D ) is difficult enough to write without imposing
> potentially project specific restrictions on GC.

Would it be conceivable to make GC pluggable in some way?  I think part of
the problem some people may be having is that each different GC algorithm
has strengths and weaknesses and sometimes the weaknesses involve make Lua
unsuitable for their specific tasks.

For example, I find the current stop-n-go, mark/sweep algorithm just fine
for the kind of work I do.  I like it.  It's small and it does the job I
need it to do with no muss, no fuss, no bother.  Were I a game programmer,
however, I might very easily find the stop-n-go part of it to be
unacceptable.  An incremental, generational system would, indeed, be better.
On the other hand if I was doing something which required anything even
remotely hard in time requirements, even a generational system wouldn't be
that useful -- I'd be needing some form of interruptible concurrency.

I did work with one experimental Modula-3 (IIRC) environment long ago which
had this kind of pluggable GC.  It came with three different GC systems
which could be plugged into the environment and if those three weren't
suited to your purposes, you could always code your own and put it in place
yourself.  Now being an experimental system it was grotesquely inefficient
and hugely bloated, but I don't think this was a necessary trait -- it
reflected, rather, the hastily-assembled nature of the product.