Re: Simpler Garbage Collection

[Richard Frith-Macdonald]

On 6 Jul 2008, at 14:00, David Chisnall wrote:

> So, I've been thinking for a while that the implementation of GC  
> that Apple seem to have settled upon is, to be polite, a complete  
> disaster.  The need for weak pointers means that it has no  
> advantages over ref counting and lots of disadvantages.

I think that's a little unkind ... it has the advantage that you never  
need to call retain, release, or autorelease.  Probably to most people  
that's all GC is about.  They aren't interested in performance or in  
how you deal with tricky cases, just in the fact that with GC you can  
(for many applications) simply pay no attention to the issue whatsoever.

> One thing that Apple seem to have forgotten is that reference  
> counting is a form of GC - replacing it with a tracing collector  
> doesn't make much sense, especially if it's a very poor tracing  
> collector,

From a technical viewpoint I agree.

> and adding GC to the compiler, rather than the library, goes against  
> the spirit of Objective-C.

> Reference counting works quite well, and doesn't have very large  
> overheads (it also plays nicely with swapping, which tracing doesn't  
> and leads to some quite pathological behaviour if you have low  
> memory), but it has one significant flaw - it doesn't handle  
> cycles.  Adding a cycle detector to NSObject seemed like a better  
> solution.
>
> I recently came across a paper from 2001 which suggests exactly  
> this.  They observe that you only need to scan for cycles when - 
> release is called and the retain count is > 0.  They propose a very  
> efficient algorithm for doing this, which we can make slightly more  
> efficient (they suggest deferring the cycle detection.  If we defer  
> it until the current autorelease pool is popped then we can delete a  
> load of objects that might have been cycles and carry on).
>
> I have started implementing this, and it shows potential.  For now,  
> I will develop it in an external framework, and move it into GNUstep  
> base later if other people are interested in it.

Sounds good.

> One other thing I have been pondering is altering the behaviour of  
> NSAutoreleasePools so that:
>
> 1) +alloc adds the newly-created object to the autorelease pool.
> 2) -autorelease is a no-op
> 3) Objects are only free'd when their ref count is 0 and the top  
> autorelease pool is pop'd.
>
> This would make interacting with GNUstep from other languages (which  
> expect full GC) simpler, and would simplify memory management since  
> every created object would have a refcount of 1 (irrespective of how  
> it was created) and autorelease would never need to be explicitly  
> called.
>
> Thoughts?

I think the requirement to use thread specific memory makes the use of  
autorelease pools very expensive in comparison with direct use of  
retain/release, so I'd be interested in knowing exactly what the  
performance penalty of this approach would be.  Thae other issue would  
be the difficulty of converting existing code to use that mechanism. I  
guess all code which used alloc/new to create objects intended to  
persist outside the current autorelease pool, would now need to  
perform an explicit retain to match the implicit autorelease on  
creation.  That's a lot of code to change.

My general thoughts are that while these suggestions are interesting  
and worthwhile, they don't address the main issues for GNUstep:
1. Apple compatibility
2. Ease of use ... for the inexperinced programmer to be able to  
ignore the issue of memory management in most cases.

The alteration of autorelease pool you suggest obviously goes some way  
towards solving the second issue ... do you have ideas about the first?