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

[Vladimir Kozlov]

I would like to push it as it is. We can look on how to verify ciTypeFlow later 
if we hit a problem again.

Thanks,
Vladimir

Christian Thalinger wrote:
> On Sep 20, 2012, at 7:48 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> 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 osr_start block in ciTypeFlow info. C2 generates runtime checks for locals and uncommon_trap 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.
> 
> It would be nice to have some extra machinery that verifies the type model but is it worth the effort?  How many bugs did we have in the past?  The only thing I'm worried is that bugs like this one might go by unnoticed because it just triggers some weird compilations (and possibly a slowdown).
> 
> -- Chris
> 
>> Vladimir
>>
>>> — John
>>>
>>>
>