Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful

FROM : Alastair Houghton
DATE : Tue Feb 05 13:40:06 2008

On 5 Feb 2008, at 00:14, John Engelhart wrote:

> I had such high hopes for Cocoa's GC system because once you're 
> spoiled by GC, it's hard to go back.
>
> Unfortunately, the 4-5 months of time I've put in on Leopard's GC 
> system has not been nearly as pleasant.  It has been outright 
> frustrating, and it's reached the point where I consider the system 
> untenable.


Honestly, this point has now been answered over and over.

I think it comes down to the fact that you have failed to appreciate 
that Cocoa GC is designed for easy use with *OBJECTS*.  If you're 
using it with objects, it "just works".

The only problem you've been able to demonstrate is in a situation 
where you are doing something that would never have worked under the 
autorelease model.  And you've been told that you need to add __strong 
in that case, *because* the compiler won't automatically pick that 
pointer out as being a pointer to GC'd memory.

All of the rest of your post is worry about nothing.  You can't create 
any of the problems that you claimed to be concerned about (e.g. 
collections destroying temporary objects), and you had misinterpreted 
the write barriers as something that they weren't (if you have the 
Garbage Collection book, I don't know why you did that; it's explained 
quite clearly in there).

As far as objects "not being special", they *are* special, in that the 
compiler generates layout information and method signatures for them. 
AFAIK the layout information (albeit in a slightly different format) 
is used by the garbage collector when scanning objects, which is 
another reason that you need to use __strong on instance variables if 
they point to non-object garbage collected memory.  FYI, the Boehm 
collector can also take advantage of layout information, so you could 
create the same issue with that collector too; the only reason that 
you don't often see it is that programmers are generally too lazy to 
specify the pointer layout of their memory blocks and just let the 
collector conservatively scan everything, which, of course, is slower 
and more error prone (i.e. greater likelihood of leaks).

As for your example:

> - (const char *)hexString
> {
>  char *hexPtr = NULL;
>  asprintf(&hexPtr, "0x%8.8x", myIvar);
>  return(hexPtr);
> }


That method is just badly designed.  You shouldn't be returning 
malloc()'d memory from a method like that; at the very least you 
should name the method to indicate that you're doing something funny 
with memory ownership, e.g.

  - (void)getHexString:(const char **)mallocedResult
  {
    asprintf(mallocedResult, "0x%8.8x", myIvar);
  }

but better yet, why not do

  - (NSString *)hexString
  {
    return [NSString stringWithFormat:@"0x%8.8x", myIvar];
  }

or if you absolutely must return a const char * pointer,

  - (const char *)hexString
  {
    return [[NSString stringWithFormat:@"0x%8.8x", myIvar] UTF8String];
  }

which has the benefit of working exactly like -UTF8String.  If you 
*really* wanted, you could mess about with NSAllocateCollectable().

Kind regards,

Alastair.

--
http://alastairs-place.net