Spread problem with > 10 arguments

Rémi Forax forax at univ-mlv.fr
Mon Jul 6 06:43:22 PDT 2009


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
>   




More information about the mlvm-dev mailing list