Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations

[Rémi Forax]

Hi Mark,
the throttle occurs if you deoptimize an already JITed callsite 10 times.
If the callsite is not JITed, you can call setTarget() without triggering
the throttle logic.

So the main problem you will have is if your program always calls
very often the same hot code and is really big.
Because your code is big, you will have to flush the callsites,
so you will flush the hot code which will be recompiled just
after (because it's a hot code). After 10 flushes, you will see
a performance degradation because your hot code will be
no more JITed.

Rémi

On 09/18/2011 05:31 PM, Mark Roos wrote:
> 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110918/234c4b82/attachment.html