views:

204

answers:

2

MonoTouch has automatic garbage collection on the iPhone. Couldn't someone prematurely implement garbage collection for Objective-C on iOS? I'm not the guy to do it, but I'm curious as to why or whether this is impossible.

I know that projects like this exist: what does it take to use them on iOS? Since they are in C/C++ anyway, and Objective-C contains those languages as subsets, but yet, those languages are actually aware of the system architecture... I'm out of my depths here...

While we're here, if anyone knows of any attempts to implement a GC on iOS, links would be helpful...

+1  A: 

Nothing stops you from building your own garbage collector for your app. Or importing another project that will handle it. Again, for your app.

more discussion:

http://stackoverflow.com/questions/416108/is-garbage-collection-supported-for-iphone-applications

Oren Mazor
Thanks. I was kind of hoping for some links to how to do it, not more information on how to work with retain/release. I've already got my brown belt on retain/release.
Yar
good point. I definitely read your question as more about philosophy than implementation. I think most of the replies you'll get are going to be the former rather than the latter. Anyway, it shouldn't take much to add one of the c/c++ gc, I would think. I think you can probably just start using them in your project without any special preparation.
Oren Mazor
Thanks, the question was probably worded for the cafe I was sitting in when I wrote it, so you're right. I should try this, I guess, but I have no idea how a GC would play with the objective-c ref counting stuff.
Yar
it probably wouldnt. you'd need the whole thing to be completely disjoint.
Oren Mazor
+4  A: 

I don't think it's possible. The problem is that Objective-C is used inside the system library too. In OS X where garbage-collected Objective-C is supported, there are in fact three modes when you compile a code:

  1. the function compiled can be only called from non-GC environment.
  2. the function compiled can be only called from GC environment.
  3. the function compiled can be called both from GC and non-GC environment.

See the discussion here, for example. The point is that the system library needs to be in the third mode in order for the OS to support both non-GC and GC apps. And in OS X, the libraries come in this hybrid mode. In iOS, I guess it comes in the mode 1. (I don't know for sure because I haven't jailbroken my phone, though.)

If you have complete control over both the system library and your app, it's possible to make them all garbage collected, but unfortunately we're not in that stage yet.

I'm sure we'll have GC in iOS in two years.

Yuji
This is basically the dealbreaker. I don't imagine it would even be too hard to port the OS X libauto garbage collector to the iPhone, but it would be useless because the system libraries wouldn't support it.
Chuck
Also, the garbage collector on the Mac works reasonably well because it can collect on a background thread. On a multicore machine (all shipping Macs for a while now) this can run without interfering with the performance of the main application. We don't yet have multicore iOS devices, so I'd expect this only after they come out.
Brad Larson
Thanks @Yuji, @Chuck, @Brad Larson.... I kind of guessed that it mustn't be easy otherwise it would already exist as a third-party lib. How ironic that the MonoTouch guys get a GC (even for framework classes, I think) and in obj-c we don't.
Yar
@Chuck, @Brad, you also need to tell the compiler's ARM backend to generate write barriers...
Yuji
@Yar MonoTouch needs to bridge C# and Objective-C. The GC is taken care of when C# objects are translated to Objective-C objects; it's part of what they need to do anyway. If you're sufficiently industrious, you can write a compiler of "Objective-C with GC" down to "Objective-C without GC", just as MonoTouch is a compiler from "C# with GC" down to "Objective-C without GC". This way you can circumvent the problem that the system library doesn't support GC. The compiler `clang` is open-sourced, so you can do that if you'd like :)
Yuji
@Yuji, thanks, I'll keep that as a theoretical possibility for now ;)
Yar