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

[Tom Rodriguez]

Why is clearing the count the right solution?  I understand that it makes the code work but it's clearing actual history too so that the call site doesn't reflect what was actually invoked.  A call site could suddenly look monomorphic when in fact it isn't.  I guess I would have expected that the count of the cleared row would be added to the count.  Also I think the logic that clears the slots should repack the entries so that none of the earlier slots are empty.

tom

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
>