RE: Incremental garbage collection coming to Lua soon?

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

> From: David Jones [mailto:drj@pobox.com]
> As deployed the collector is a mostly copying read barrier collector:
> the Dijkstra tricolor invariant is maintained by turning grey objects
> black whenever the mutator attempts to read a grey object.  The
> Virtual Memory page protection system is used to implement the read
> barrier meaning that the mutator has no extra code to implement the
> read barrier.

How does this work? Is the VM managed in software, not hardware? Are you
suggesting an (optional?) VM type system for Lua so a copying collector
could be written?


> > 1) Refcounting work is proportional to mutator changes, not heap
> >    size. Every copying or sweeping collector I've used breaks down
as
> >    the heap gets even moderately big.
> 
> Our collector works fine up to 500MB and beyond, it has a scalable
> architecture and is designed to work well at any size, including in 64
> bit address spaces.
> 
> Your statement swings both ways of course, imagine the number of
> reference count changes that sorting an array of strings involves.

I think deferred RC would alleviate this, but I take your point.


> > 3) Pausing collectors are a constant nusance holding back the
> >    capabilities of languages with garbage collection.
> 
> There are incremental collectors with bounded pause times.

What would you suggest as heuristics for bounding collection in Lua?
Would you do it on a timer? It would be nice to be able to specify an
amount of time that you could delegate to Lua for collection. Or,
perhaps some sort of volatile flag could be checked by Lua whilst GC'ing
so that you could interrupt it at will - e.g. on a timer or when you
exit an idle period - mmm which suggests multiple threads. Or, perhaps
there could be a call back to the client application periodically to
check whether GC should wind up. In time sensitive environments the
client application needs to make a call how important GC is and do as
much as possible when under low stress. GC pauses will no doubt become
necessary in extreme circumstances on limited systems to avoid
allocation failures. It would be nice to have plenty of control over
when this happened.


> > 9) Copying/compacting collectors which use handles to facilitate
> >    object movement increase the overhead of using all pointers due
to
> >    the the handle-indirection cost. For most programs this is worse
> >    than the increased mutator cost of reference counting.
> 
> Quite possibly so, but noone has suggested that yet.

Ah, this perhaps answers my first question.



Regards,
Nick