hg: mlvm/mlvm/jdk: meth: add proxy maker for closures

[Rémi Forax]

[...]

> One important question for me is how multi-method interfaces would be
> handled. I had originally tried to use Scala's "Function" interfaces
> in Duby to represent closures, but they all have multiple abstract
> methods that must be handled completely differently. I'd need to
> provide my own superclass with default behavior or have a way to
> stitch together N handles for N abstract methods.
>    

You can construct a tree of method handles,
like Attila's code does.

> And I agree about the language bridging...plus in the JRuby case, this
> actually makes Ruby to Ruby bridging easier:
>
> * We need a codebase that works on Java 6
> * ...so we can't move our entire call path to using MethodHandle
> * ...so we need our own abstract "invoker" supertype
> * ...so being able to use that supertype with either generated impls
> or MethodHandle-provided impls makes it easier for us to support both
> indy and non-indy runtimes in the same implementation.
>    

I think that you should maintain two codebases
(I am not kidding),
because to really unleash the power of JSR 292
you have to use MethodHandle every where.

If all your codebase use method handles, you
don't need boxing anymore along the whole path,  you can
jump back and forth between the interpreter and the
runtime compiled code, you can share dynamic stubs
(by example the one you use to resolve the operator +)
between the interpreter and the runtime compiler,
and even try to share profiles between them
(I say try here because I have only a hackish solution)
etc.

And you can do all of that with the few lines of codes
because the API allow you to work at a meta-level.


> Perhaps this also helps Java 7 closures work nicer by making it
> possible to have a generic Closure or Function superclass completely
> independent of java.dyn? Or by making it possible to implement
> (faster) Java reflection with fewer generic frames under the covers
> via a single abstract supertype populated by indy?
>    

And your generic Closure/Function will be not a lot of
different from a method handle.

> Seems like a good addition, in any case, but especially once it's
> faster and more direct than reflect.Proxy :)
>
> - Charlie
>    

Rémi