Assuming that we can handle the ReturnNode case, I think that this is a really good idea. Imagine being able to scale better that MRI because JRuby could share the Rails code.
Java usually gives the impression of having a heavy runtime, but if we can turn the situation around by cloning the AST and other immutable data, this should be a compelling reason to choose JRuby over MRI - essentially, we can make the argument that as soon as you need to scale beyond X (2? 3?) instances of Rails, JRuby would actually be more memory efficient than MRI. On a side note: Could compiled code be shared too? Peter -----Original Message----- From: Ola Bini [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 7:34 AM To: [email protected] Cc: Jon Tirsen Subject: [jruby-dev] Cloning a Runtime Hi, Jon Tirsen proposed that a nice thing for Goldspike would be to share the AST's between runtimes, to avoid the huge memory impact and performance of loading Rails over and over again for a new runtime. I'm wondering whether this is something we should do. Basically, we could implement org.jruby.Ruby.clone, which would return copies of everything in the current runtime, except that all AST links points to the same AST as the first one. To make this feasible, we would need to remove runtime dependent information from the AST. As far as I can see, there are only three nodes which cache information of some sort connected to a runtime: FixnumNode RegexpNode ReturnNode (target) Now, both FixnumNode and RegexpNode would be quite easy to exteralize into some other cache outside the AST. The main problem would be the ReturnNode, where target is a RubyObject (I think). Anyone have any opinionss? Would it be worth doing? Cheers -- Ola Bini (http://ola-bini.blogspot.com) JRuby Core Developer Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) "Yields falsehood when quined" yields falsehood when quined. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
