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

[Vladimir Kozlov]

Thank you, John

John Rose wrote:
> Two comments:
> 
> Typo: s/polimorphic/polymorphic/

Fixed.

> 
> 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?

It seems, you missed my changes for 6614597 :) The count field is not inclusive any more.

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87684f1a88b5

Vladimir

> 
> -- 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
>>
>