Request for reviews (S): 6923002: assert(false,"this call site should not be polymorphic")

[John Rose]

Two comments:

Typo: s/polimorphic/polymorphic/

The count field of a call site is inclusive of the counts on the rows.  Therefore, I think you should decrement the main count by the row count, rather than zero it out.

Correlated profile numbers is not good design however.  We should (not in this bug) change InterpreterMacroAssembler::profile_virtual_call to increment the main count only if a row count is not incremented.  That way, the total count of the call site will be the sum of all counts (which then are disjoint).  And the main count becomes a "default" or "misc" count.  Does this make sense to you?

-- John

On Feb 4, 2010, at 9:43 AM, Vladimir Kozlov wrote:

> 
> http://cr.openjdk.java.net/~kvn/6923002/webrev
> 
> Fixed 6923002: assert(false,"this call site should not be polymorphic")
> 
> Problem:
> After the 6614597 changes C2 expects that the MDO total count at the virtual
> call site indicates only polimorphic case and the assert was added for that.
> But ReceiverTypeData::follow_weak_refs() may clear a receiver information
> in MDO leaving the data at strange state and causing assert.
> 
> Solution:
> Clear also the total count when a receiver information is cleared.
> An additional receiver, if it exists, will be recorded in the cleaned row
> during next execution of the call site.
> Also add method name for the assert output and record in logs a second
> receiver even for polimorphic case.
> 
> Reviewed by:
> 
> Fix verified (y/n): y, test
> 
> Other testing:
> JPRT
>