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

[Vladimir Kozlov]

Thank you, John

I will look on Reason_constraint. Current usage of Reason_unreached for runtime 
verification of OSR input types is confusing. I agree, that Reason_constraint is 
more suited for this.

Thanks,
Vladimir

John Rose wrote:
> On Oct 2, 2012, at 10:18 AM, Vladimir Kozlov wrote:
> 
>> I would like to push it as it is. We can look on how to verify 
>> ciTypeFlow later if we hit a problem again.
> 
> Yes, go ahead and push it as it is.
> 
> I wish it could be an error (instead of an uncommon trap) for the 
> data-dependent preconditions to be false on entry to an OSR method.  But 
> as we talked about at lunch, and as the code in load_interpreter_state 
> and check_interpreter_type points out, there are sometimes reasonable 
> circumstances when an OSR method will encounter a type that TypeFlow 
> does not expect.  The basic reason is that TypeFlow deletes paths which 
> the interpreter can later add.  Comment from parse1:
>     // The unexpected type happens because a new edge is active
>     // in the CFG, which typeflow had previously ignored.
>     // E.g., Object x = coldAtFirst() && notReached()? "str": new 
> Integer(123).
>     // This x will be typed as Integer if notReached is not yet linked.
> 
> Idea:  Consider using a more distinctive DeoptReason for this case.  We 
> have Reason_unreached; maybe use Reason_constraint instead.
> 
> Thanks,
> 
> — John