All~ Couldn't the VM detect hot mega-morphic methods and have them bestow some of their hotness upon the callers. Making their callers more likely to inline them. Then you have a different call site for the each which is likely to be monomorphic.
Matt On Thu, Jun 21, 2012 at 10:30 AM, Rémi Forax <fo...@univ-mlv.fr> wrote: > On 06/21/2012 04:12 PM, Jochen Theodorou wrote: > > Am 21.06.2012 16:00, schrieb Rémi Forax: > >> On 06/21/2012 03:52 PM, Jochen Theodorou wrote: > >>> Am 21.06.2012 13:57, schrieb Krystal Mok: > > [...] > >>>> I wonder how well the new interpreter design in Graal would handle > this > >>>> kind of case, since it's supposed to have picked the good parts from > >>>> trace-based compilation, but without actually having to do tracing. > >>>> Can't wait to see more details of it at this year's JVM Language > Summit. > >>> If I understood Thomas right, then Graal doesn't have that problem. > >>> Afaik hotspot doesn't have to have that problem too. It just was a > >>> design decision not to make call site caching per execution path. Afaik > >>> chaning that now would take quite some effort, but is not impossible. > >> You can create the execution path backward, when it's needed. > > I was thinking that the VM can create the path backward. > > > you can in PHP.reboot, but in Groovy I don't have access to the full > > execution path. Inside "each" I don't know what did call me and at the > > point of where I call each, I don't see what each will actually do. > > yes, but you can detect that 'each' is a special method because > it takes a closure (Closure) as parameter and try to do some magic. > > > > > bye blackdrag > > > > Rémi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
