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<[email protected]> 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 >> [email protected] >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> > > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
