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
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
