Re: perl 6 requirements

Alan Burlison wrote:
> 
> Hildo Biersma wrote:
> 
> > In item 2.4 (garbage collection), we need to make sure there is an
> > alternative for people that need guaranteed cleanup time of their
> > objects (such as SelectSaver).  To a large extent, this could be solved
> > by having a special kind of 'Guard' object in the language that either
> > is reference-counted or cleaned up when the scope it lives in is exited;
> > the 'Guard' object can then run a 'finalize'-like cleanup method for the
> > object it is guarding.
> 
> The trouble with all automated garbage collection schemes is that they
> tend to be non-deterministic.  Having your program grind to  a halt at
> irregular intervals is not a good thing.  What about some sort of
> hybrid, using reference counting as the first and default way of
> reclaiming memory, with a full GC pass at selectable points, e.g. never,
> every n seconds, whenever a block bigger than a given size is allocated,
> at interpreter instance exit, on demand etc.  The existing refcount
> mechamism has worked well, and has predictable behaviour.  It seems a
> shame to throw it out in favour of something that in most cases probably
> won't work as well.

This issues was raised as well at Chip's talk at TPC.  The answers, as
far as I remember:

- Garbage collection has improved massively over the past decade
  and is now usable.  Example: gcc 3, which ahs switched from manual
  memory management to GC, is faster than before and uses less memory.
- Garbage colelction can be faster than refcounting because
  you save the continual increment/decrement operations that
  plays hell on caches.
- A hybrid scheme has the disadvantages of both: it uses
  extra memory and poluutes cache, and then you still run GC.
- More deterministic GC schemes than stop/start exist and seem to be
tolerable.

And hey, if we go for GC in perl6, we'll be sure to pick a *good*
system.

Hildo