Loop handle

[Charles Oliver Nutter]

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 <james at thorpeweb.com> 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, mlvm-dev-request at openjdk.java.net 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
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>