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@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
