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

[Tom Rodriguez]

On Feb 4, 2010, at 4:07 PM, Vladimir Kozlov wrote:

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

You're right.  The code will all deal with this correctly.

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

Agreed.  I'm ok with the changes then.  One more typo s/Cleare/Clear/.

tom

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