Request for reviews (S): 7199742: A lot of C2 OSR compilations of the same method's bci
john.r.rose at oracle.com
Tue Oct 2 10:30:07 PDT 2012
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev