Hi Jon, On Jan 28, 2010, at 9:12 PM, Jon Olson wrote:

Hi folks,

I'm new to the list, but I checked the archives and I don't *think* what I'm suggesting here has been suggested/done before.

I've been putting some effort towards getting MacRuby going on the iPhone. After reviewing the GC situation, it seems like using the Boehm collector and simply pointing CoreFoundation's default allocator at it would be a good solution to get things up and going. Cocoa seems to use CF's default allocator for a default calls to alloc, so I think this covers most allocations that you'd expect to see. Also, since you can bind free() to NULL when creating an allocator, it seems like you can largely negate the effect (if not the performance hit) of Cocoa-internal autorelease pools releasing all of your resources.

I've managed to produce an armv6 build of Boehm and an armv6 build of the macruby libraries. I've also talked macrubyc into spitting out ARM executable code (by just tweaking the LLVM target). Anyway, I figured before I went much further I'd express my intent and make sure I haven't duplicated too much of anyone else's work.

Does anything I'm suggesting sound totally crazy?

Great stuff! So, if I understand your idea correctly, you want to create a custom CF allocator that uses the boehm primitives with a no-op free and register it as the default allocator. Then further object allocations would use it. This is a brilliant idea, I would love to hear how it works in practice though :) I suspect the CF allocator might not be called in all cases, and that creating a custom malloc zone for boehm might work better. A problem I can see is that we would still need to honor the dealloc methods of objects. Maybe by plugging some functionality during the GC finalization phase? As part of the big picture, we must find a way to precompile bridgesupport signatures in the binary during the macrubyc phase. Then, we must generate bridgesupport signatures for the iPhone SDK. The best thing is probably to hardcode this in the VM. Then, we should reduce the libmacruby-static.a binary, removing the LLVM bits and disable Ruby features that require it. If we get all of this working, then I think we are green :) Laurent