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<[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
