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

[Mark Roos]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110918/0f0fe350/attachment-0001.html