discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simpler Garbage Collection


From: Richard Frith-Macdonald
Subject: Re: Simpler Garbage Collection
Date: Sun, 6 Jul 2008 14:57:50 +0100


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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]