On 06/21/2012 03:55 PM, Jochen Theodorou wrote: > Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy): >> Yes, it is very easy for those sites to become megamorphic. We work round >> this by using exactInvokers on function invocation call sites, and caching >> on the method type of the functions rather than the types. > So in my own words... you don't check on the type of the lambda, but on > what it takes as input, thus you get no changes for differing lambdas. > Is that about right? That's a nice idea, indeed > > bye blackdrag >
at least you will not change the inlining cache too often and you can adapt arguments for several method handles but the VM will not consider the method handle as constant so it will not be inlined with the code of the loop. Another way is to transform the high order function (each() in your example) as a method handle tree but the JSR 292 lacks a loop combiner. In Groovy, you can also duplicate the bytecode of the high order function when you are able to emit bytecode at runtime, see [1]. Said differently and with Hotspot in mind, an idea is that you can execute a code but with another profile metadata object that the usual one. Because Hotspot is already able to generate code with a profile object created by the interpreter (for tiered compilation), having a way to ask for a specialized version of a method with a fresh profile doesn't seem too hard but it's more a hack than a real answer. Rémi [1] http://weblogs.java.net/blog/forax/archive/2011/04/08/fixing-inlining-%E2%80%9Cproblem%E2%80%9D-prototype _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
