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

[Rémi Forax]

Le 25/05/2010 22:57, Charles Oliver Nutter a écrit :

>    
>> 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)?
>    

You can compile ahead, that's not what the backport does,
and you will face the same problem that JRuby currently have.
You will have to generate lot of stubs that will need to be
included in the dex file.


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

As I previously says, you should maintain two code bases.

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

Rémi