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

[Vladimir Kozlov]

First, all our profiling logic works with empty rows in any slot.
I verified it since I also thought about repacking but it is not necessary.
We do sorting when building profiling info (ciCallProfile) for compilation.

Also I intentionally want to make it monomorphic since it allow to have
more accurate profiling information because there was execution phase change
(klasses were unloaded). And if the site still polymorphic MDO will be updated
to reflect it. But it could be the case that the site becomes only bimorphic.
Then keeping total count not 0 will be wrong.
Even if we use monomorphic (when it is not) for compilation we will only have
trap, deoptimization and recompile again with updated MDO (after executing method
in Interpreter).

Thanks,
Vladimir


Tom Rodriguez wrote:
> 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
>>
>