Hi Remi, yes, I remember the discussion you had with John. I was there too ;)
Am 21.12.2012 00:32, schrieb Remi Forax: > On 12/20/2012 11:44 PM, Jochen Theodorou wrote: >> Am 20.12.2012 22:35, schrieb Mark Roos: >> [...] >> > [...] > >> >>> Another thought I had was to determine if a method has megamorphic call >>> sites internally and if so >>> then creating new methods during my lookup rather than caching the >>> existing ones. This would move >>> the specialization up one level but the internal sites would now be >>> monomorphic >> ignoring that I cannot easily do that, this surely is an approach, but I >> am worried about memory here. For one you would have a tendency to keep >> references to class you may garbage collect otherwise, for the other >> your class would grow and grow... > > The real solution is to have a way to say, I want a method handle on a > method but with a fresh profile. > John and I discuss about that after the last JVM Summit, he says that > being able to separate the profile from the method will be hard to do in > Hotspot. > > The main issue with the duplication of methods at bytecode level to have > several profiles is that the freshly generated bytecode have the wrong > performance counter and can be considered by the JIT has never been > called or at least not called enough to be JITed. > This is a known issue of the current implementation of JDart. > > A compromise can be to have a way to read/write the profile and the perf > counter of any methods, > Graal already provides these features. > It will be also very useful when you want to test a Java code to be able > to inject a profile artificially. > >> >> bye Jochen > > cheers, > 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
