Spread problem with > 10 arguments

[Fredrik Öhrström]

Can a JavaMethodHandle have >10 arguments?

//Fredrik

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
>