[MacRuby-devel] MacRuby on the iPhone

Laurent Sansonetti lsansonetti at apple.com
Fri Jan 29 13:19:36 PST 2010


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


More information about the MacRuby-devel mailing list