Rémi Forax skrev: > The problem is that for some adapters (by example collectArguments) > the bytecode size grow following a quadratic curve in relation to > the number of arguments. > This means that if you have more than let say 10 arguments the size of > bytecode for such adapters disable inlining which is the mother of all > optimisations. > I am not sure I understand what you mean. Please, have a look at my example of CollectArguments implementation here: http://blogs.oracle.com/ohrstrom/2009/05/pulling_a_machine_code_rabbit.html#Collect
The size of each adapt method grows linearly with the number of arguments. This will not prevent inlining. > A minor correction. The backport doesn't generate a call chain > but inline the method handles chain into a single block of code > containing only end method calls. > This is what I meant. :-) The only reasonable way to optimize a chain of method handles is to inline. This is true both for your backport code and the JRockit example I gave. > Let me try to summarize : > - current spec require a == check before calling a sequence > of adapters that ends with a call to a Java method. > Yes, a single comparison is necessary, for each method handle invoke in the adapter sequence, that the call site method type is identical to the methodhandle target method type. If ok, call the destination otherwise throw an Exception. > - generic invocation (variant invocation) requires > to check the number of argument at call site and > to ensure that only a valid method > (contravariant of parameter types/covariant of return type) > by inserting cast where needed. > The simple change to JSR292 is that every argument handed to a method handle invoke, will be cast to the target argument type. Potentially boxing/unboxing. If the number of arguments differ, give up. Co/contra variance will follow. The effects of generic invocation only happens when the current spec would have thrown an InvocationTargetException. Therefore it >must< be compatible for every application that does not rely on an exception to be thrown. You can check if a cast is really needed or not, and you can go directly to the target method if the method types match exactly, and you can inline, but these actions are merely optimizations that might or might not be performed by the JVM. Going through Object references is one such optimization for JVMs that want to compile virtual method handle calls that cannot be inlined. But to the outside, it simply looks like the arguments are cast to the target argument types. //Fredrik _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
