>From Christian > The optimistic optimization for MutableCallSite and VolatileCallSite > invalidate compiled methods on every setTarget. This possibly results > in a recompile. For ever-changing call sites this is a performance > hit.
What is the use model of callsites which drives this? In my case I am using callsites as inline caches so I would expect a flurry of set targets as the initial classes pass though and then occasional sets as new classes show up. The depth is usually about 1 or 2 but sometimes a lot more ( megamorphic ) The other problem is that the sites become stale after awhile so what I do is flush them all ( it would have been nice if that was easy, implied switch point) and let them rebuild as the new classes go by. It seems like it would be hard to differentiate callsites which are always changing from ones which are simply megamorphic or have just been around so long that they have seen lots of classes. By the way how many changes until you throttle? As in my case the GWT is a simple extract field, compare and jump. It would be interesting if the optimization realized that and created a different optimization when the site has lots of targets in its chain. For instance switching from a series of tests to a vTable like lookup. Or maybe just let me specify this some way. Perhaps this argues for finer grain control on the callsites themselves. Providing hints to the optimizer rather than depending on heuristics seems safer at the point in their evolution. At least a way to reset them to some initial state would be helpful as we are creating dynamic languages which are expected to run for long periods. Since this does seem to impact my means of dealing with stale sites do you have any thoughts on an alternative approach? regards mark
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
