Am 20.12.2012 22:35, schrieb Mark Roos: [...] > I see the same for my Smalltalk implementation. In looking at my > problem it seems that the > megamorphic problem is temporal. In other words over a short time > period the site is monomorphic > then becomes megamorphic as more code runs.
yes, that is what I expect. A callsite could be monomorphic for a long time, then be megamorphic and then turn monomorphic again. > Currently I detect the depth of the call site and drop its target chain > when it gets too deep. Now this > site starts over. I am sure the JIT is not thrilled and it is not a > general solution but for now it seems > OK. well, looking at what I said before, this approach has a good chance of "cleaning" a call site. That is why I tihnk this approach is surely not bad. How many targets do you usually keep in the chain before dropping? > Longer term I was thinking of a way to determine if a site is > megamorphic and if it is replace the callsite > GWT with something tailored. In my case the code is usually the same > for all receivers so it would > be interesting to find a way to use the same method code and only look > for the receivers where the > code changes. hmm... for Groovy I don't think I can really tailor something down all that much. If I can, then I didn't see it yet. > 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... bye Jochen _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
