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

[John Rose]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121002/a476e0ed/attachment.html