Spread problem with > 10 arguments

[Fredrik Öhrström]

Because in the source code for JavaMethodHandle you will
see an example of the combinatorial explosion of possible
method types that I am flagging as a serious problem
unless generic invocation is supported.

Even with the clever compression scheme already in place,
it seems to me (please correct me if I am wrong) that
JavaMethodHandle requires 180 methods to handle up to 5 arguments.
With up to 10 arguments it would have to implement 605 methods
and with up to 20 arguments it would have to implement 2205 methods.

I think this signifies more than just a tricky implementation matter.
It is a clear indication that managing all possible signatures is something
that should be inside the JVM and not implemented in bytecode.

Also, since the performance question for smaller JVMs is often mentioned,
I would like to compare the situation with closures. Apparently a lot
of people would like to see closures in the Java.

It is indeed possible to compile a closuresq for loop as efficiently as a
standard Java for loop. However the optimizations needed to do this are
approximately: inlining, escape-analysis, object explosion.

These are the same optimizations needed to optimize MethodHandle
generic invocation efficiently! But no one complains that closures should
not be added to Java because non-optimizing JVMs will not execute them as
efficiently.

I think that any reasonable JVM that is interested in any sort of
performance will have some sort of optimizer. Heck, even the JVM running
inside the SIM card in a modern GSM/3G phone can now execute at a couple of
hundred MHz and have 1 GB of memory! :-)

//Fredrik

Rémi Forax skrev:
> Fredrik Öhrström a écrit :
>   
>> Can a JavaMethodHandle have >10 arguments?
>>   
>>     
>
> Why it can not ?
>
>   
>> //Fredrik
>>   
>>     
> Rémi
>
>   
>> Rémi Forax skrev:
>>   
>>     
>>> Charles Oliver Nutter a écrit :
>>>   
>>>     
>>>       
>>>> On Sun, Jul 5, 2009 at 1:17 PM, Rémi Forax<forax at univ-mlv.fr> wrote:
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> Else, for slow paths, you can use a JavaMethodHandle and store
>>>>> all you need using fields instead of insert them as arguments.
>>>>> It's very difficult to write a JavaMethodHandle that doesnt not box/spread
>>>>> to handle polymorphic signatures that why I think it should
>>>>> only be used to handle slow paths.
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> The down side of constructing a JavaMethodHandle is that if the
>>>> additional arguments to the test are different we'd end up
>>>> constructing new every time. 
>>>>     
>>>>       
>>>>         
>>> Just to be sure, every time here means every time you create a method handle
>>> and not every time a call is done.
>>> In my opinion, It's not a big deal, we know that with the current API
>>> we have to create five to twenty objects by call site just because
>>> all method handle adapters are reified.
>>> [the other solution is to express method handle adapters using builders]
>>>
>>> Even if an optimizer (compiler/JIT) is able to reduce a method handle tree
>>> to a small code blob without any stack frame, the method handle tree
>>> will stay in memory because the optimizer will be called only if
>>> the call site is hot.
>>>
>>>   
>>>     
>>>       
>>>> Obviously avoiding arg boxing is key to
>>>> performance, so call paths will need to support a large number of
>>>> unboxed arguments to allow passing call protocols along cleanly.
>>>>   
>>>>     
>>>>       
>>>>         
>>> One nice goal will be to be able to express call protocol with only one 
>>> object
>>> or more likely two, one storing the dynamic part which flows in the 
>>> stack and
>>> an other for the static part which is stored in the call site object.
>>>
>>>   
>>>     
>>>       
>>>> I'll play around with things a bit and see if there's anything
>>>> specific to the call site that could be generated once, avoiding the
>>>> extra arguments...
>>>>
>>>> - Charlie
>>>>   
>>>>     
>>>>       
>>>>         
>>> Rémi
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>   
>>>     
>>>       
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>   
>>     
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>