Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations
mroos at roos.com
Sun Sep 18 09:49:20 PDT 2011
After 10 flushes, you will see
a performance degradation because your hot code will be
no more JITed.
But I also have to setTarget on the callsites when the method code
changes. The easy (most efficient)
way is to reset them all. So after 10 replacement methods I lose all
jitted optimizations? forever?
This seems extreme to me.
Should the throttle be more sensitive to rate of change and not absolute
quantity? Or a means
to setTarget which does not count towards throttling. Or (gasp) if I
choose to do lots of setTargets
maybe I should just take the hit myself leading me to avoid the issue if
it matters to me.
Since I don't understand the use case where deep/changing chains are
common and so nned to be fast,
this seems premature to me.
I am still wondering what I would do if this is the case? Drop and
replace all methods? Do my own
callsite to somehow limit target changes ( callsite with a callsite as
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev