Because in the source code for JavaMethodHandle you will see an example of the combinatorial explosion of possible method types that I am flagging as a serious problem unless generic invocation is supported.
Even with the clever compression scheme already in place, it seems to me (please correct me if I am wrong) that JavaMethodHandle requires 180 methods to handle up to 5 arguments. With up to 10 arguments it would have to implement 605 methods and with up to 20 arguments it would have to implement 2205 methods. I think this signifies more than just a tricky implementation matter. It is a clear indication that managing all possible signatures is something that should be inside the JVM and not implemented in bytecode. Also, since the performance question for smaller JVMs is often mentioned, I would like to compare the situation with closures. Apparently a lot of people would like to see closures in the Java. It is indeed possible to compile a closuresq for loop as efficiently as a standard Java for loop. However the optimizations needed to do this are approximately: inlining, escape-analysis, object explosion. These are the same optimizations needed to optimize MethodHandle generic invocation efficiently! But no one complains that closures should not be added to Java because non-optimizing JVMs will not execute them as efficiently. I think that any reasonable JVM that is interested in any sort of performance will have some sort of optimizer. Heck, even the JVM running inside the SIM card in a modern GSM/3G phone can now execute at a couple of hundred MHz and have 1 GB of memory! :-) //Fredrik Rémi Forax skrev: > 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 > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
