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