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

[Charles Oliver Nutter]

On Tue, May 18, 2010 at 4:44 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
>
> [...]
>
>> 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.

I'm not sure I understand how this would tie into implementing an
interface or abstract superclass with many methods...can you
elaborate?

> 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.

I would honestly *love* to use indy everywhere; it would make my job
as an implementer vastly simpler. But can the backport be used
everywhere JRuby users will want to use JRuby? Can we, for example,
generate code ahead of time for Google App Engine or Android, where we
have no permission to hook into the root classloading process (or in
the case of Android, where we can't even generate bytecode on-device)?

I would throw out our current dispatch logic in a heartbeat if I knew
it were possible to still support Java 5 and 6 with a single codebase,
but frankly it's just not an option to make JRuby be Java 7-only right
now when 7 isn't even out and we have production users.

>> 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.

Yes, this is also very true, and having all dispatch via method
handles might make it easier for the JVM to see inlinable paths
through closure-receiving bodies (where right now they go megamorphic
and closures will never inline as a result...a major gap considering
all the new languages want to use closures...)

- Charlie