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

[Christian Thalinger]

On Sep 21, 2011, at 8:21 AM, Mark Roos wrote:

> From Remi 
> 
> Moreover, are you sure the code that contains these callsites is JITed, 
> 
> No,  but then how would I know and what would I do if I did know.  If its JITed 
> and I do the 10th ( or whatever) invalidate in three months because of uploading a patch 
> and because of that the app slows down until I reboot it that is a problem for me. 
> 
> Smalltalk is dynamic not just in its use of variables but in its ability to redo methods on 
> the fly ( and create new classes on demand etc).  Because of this I will need to invalidate 
> callsites in the cache.  I really don't think it will be helpful if I have to drop the methods and 
> recompile the byte codes to get 'fresh' callsites. 
> 
> Maybe I could have a way to put the site back into 'bootstrap' mode.  Maybe even with 
> a SwitchPoint. 
> 
> I think I can deal with depth control I am not sure I can deal with an 'helpful' compiler 

I got your point.  It seems we have to rework this patch a little to meet the requirements.  And I'm pretty sure it's too late for 7u2 anyway.  A rate instead of an absolute counter seems to be the way to go.

-- Christian

> 
> 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/20110921/80926841/attachment-0001.html