Charles Oliver Nutter a écrit : > On Tue, Jul 14, 2009 at 8:51 AM, Rémi Forax<[email protected]> wrote: > >> 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. >> > > This is probably the case for the backport, since you are basically > just hand-inlining the whole chain as bytecode into the original call > site. But for the full 292 implementation, it doesn't have to be the > case. The extra logic from the method handle chain can be excluded > from the inlined size and as John Rose put it "given a platinum credit > card" so any complexity of handle chain (perhaps with some platinum > upper bound) does not count against your inlining budget. >
I don't feel comfortable with this kind of "platinum credit", What I like in Java is the fact that the same rules applied to all classes, part of the JDK or not. platinium credit inlining raises questions like : If there is a way to get a platinium credit, why my application can't use it ? Am I a second class citizen ? > - Charlie > Rémi _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
