Request for reviews (S): 7199742: A lot of C2 OSR compilations of the same method's bci
vladimir.kozlov at oracle.com
Tue Oct 2 10:46:19 PDT 2012
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.
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
> // 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.
> — John
More information about the hotspot-compiler-dev