Spread problem with > 10 arguments

[Rémi Forax]

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