With tail calling, it would certainly be possible. I think the tradeoff would be accepting that you wouldn't be able to completely compose a body of code in one shot; somewhere downstream you'd have to defer a decision like whether to exit the loop or not. That would probably mean slicing the native side into pieces, at least until profiled inlining could happen.
It's worth pointing out that JRuby's current interpreter does actually inline in places, wherever the AST structure is invariant. We actually reified several variants of calls by arity and block-passing to both simplify logic and to expand the number of unique Node subtypes for Hotspot to key off. The move to composed handles would be like generating unique classes for every node instance in the system, effectively making all node to node calls monomorphic and trivially inlinable. Maybe I'll try to mock up an AST to MH translator for the pieces we can currently represent. Another important detail comes to mind now as well: when a graph of handles becomes large enough that it's no longer a good idea to compile the whole thing, it should gracefully degrade into multiple compiled pieces, rather than bailing out completely to full interpretation. That bites us surprisingly often with Ruby's very dense code...we frequently end up generating methods that are too "fat" for Hotspot's default thresholds. - Charlie On Saturday, April 10, 2010, James Thorpe <[email protected]> wrote: > This idea is a real gem! > > Would it not be possible to remove the need for a looping handle by a > CPS conversion? > > James. > > > On 10/04/2010, at 5:00 AM, [email protected] wrote: > >> >> I ask because I still have a perverse desire to follow up on an idea >> John Rose gave me to implement JRuby's interpreter entirely with >> MethodHandles...with the obvious result being that by simply composing >> a set of handles they'll already be compiled to native code for me :) >> >> - Charlie > > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
