Hi Rémi
you mentioned
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
target)?
regards
mark
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
