RE: GC order

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

> NT> An incremental garbage collection routine (with generational 
> > optimisation?! ;-D ) is difficult enough to write without imposing 
> > potentially project specific restrictions on GC.
> 
MR> 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.

I think this has been discussed before and I think the usual answer is:
Lua is not overly complex in implementation and therefore it's not
impossible to wire in your own solution. Also, a design goal of Lua is
simplicity. A generic interface to these mechanisms could slow Lua or
involve a major refactoring. And, even if you did write a pluggable
system, would people really (re)use it, and how reuseable would it be
between Lua versions? I suspect it would be difficult to draw some
lines.


> 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. 

I assume there will be some sort of tuning interface for the IGC (e.g.
objects traversed per update?) so you could just set this to a maximum
and it would behave as now? And, if we had generational optimisations it
would be doing the same job but more optimally. The size of the
performance hits wrt GC is pretty minimal anyway and this only really
becomes a problem in real time systems. GC pauses are very noticeable in
some Java implementations because Java is a huge memory glutton, whereas
Lua is more economical (less time in GC less often). 


> 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.

Incremental implementations are interruptible by definition. Eek, we
don't want (or need) concurrency! What is planned is incremental mark
and sweep. An optimisation of this would be an incremental generational
mark and sweep algorithm.


> 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.

It has been suggested that the Lua authors put in macros to implement
the write barrier necessary for the more advanced GCs. Different GC
implementations could then be built on this and a system as you suggest
would not be inconceivable. The authors have done a pretty good job
thusfar in implementing the language so I'm pretty happy to wait and see
what they surprise us with next. IGC has long been requested on this
list, above a modular implementation of Lua. Of course I'd be interested
in any comments the authors would like to make wrt your post.

Regards,
Nick