Request for reviews (S): 7199742: A lot of C2 OSR compilations of the same method's bci (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Sep 20 07:48:45 PDT 2012

On 9/19/12 11:19 PM, John Rose wrote:

On Sep 19, 2012, at 7:28 PM, Vladimir Kozlov wrote:

http://cr.openjdk.java.net/~kvn/7199742/webrev

CI type flow analysis clone the head of OSR loop and as result the type of locals is incorrect in osrstart block in ciTypeFlow info. C2 generates runtime checks for locals and uncommontrap to verify that OSR information is correct during execution. The code hit the uncommon trap, method is deoptimized, C2 does the same osr compilation again. And this repeats until PerMethodRecompilationCutoff/2 (200) is reached. Don't clone the head of OSR loop. This is a reasonable fix. Here's the part I'm missing: How do we ensure that we find the problem if something similar happens again? By "similar" I mean a serious inaccuracy in the ciTypeFlow type model. Perhaps we could add an assert which would detect the problem (e.g., null type at OSR entry point) and raise an error. Ideally, if you were to comment out your fix but put in the assert, it would fire immediately on your test case.

You need some kind of duplicated type flow analysis for that. It is not simple null or not null, the local may stay null if it is not updated in a loop but after it.

Vladimir

— John

More information about the hotspot-compiler-dev mailing list