Request for reviews (M): 6614597: Performance variability in jvm2008 xml.validation

[Vladimir Kozlov]

Thank you, Tom

Then I will go ahead to implement it.

Vladimir

Tom Rodriguez wrote:
> I think you're right that part of the problem is that even though we maintain 3 counters, the total is supposed to be related to the other two but since they aren't updated atomically they can actually be out of sync by an almost arbitrary amount.  So I think you're suggesting that instead of maintaining rec1, rec2 and total, we should maintain rec1, rec2 and other.  The site count will be the sum of rec1, rec2 and other.  Another nice thing about this would be that we'd only be updating a single counter for the call site instead of normally doing two.  The other way to handle this would be to set TypeProfileWidth to 3.  Either way, if the profile itself could reliably indicate more than 2 receiver types we wouldn't need to have a new Reason.  I like the idea of a solution like this.
> 
> tom
> 
> On Jan 25, 2010, at 10:24 AM, Vladimir Kozlov wrote:
> 
>> Reason_bimorphic will not cover the case when total counter
>> is larger then sum of 2 receivers in real bimorphic case.
>>
>> What I am saying is currently the only reliable information
>> these counters can give us is monomorphic case. We can not
>> relay on them (in current implementation) to distinguish
>> bimorphic case from polimorphic case. This is why Reason_bimorphic
>> helps. If we use counters differently we don't need Reason_bimorphic.
>>
>> Vladimir
>>
>> John Rose wrote:
>>> On Jan 22, 2010, at 10:06 PM, Vladimir Kozlov wrote:
>>>> The third solution (sorry they are still popping up) will be using
>>>> the total counter in MDO only for missing (third receiver) cases.
>>>> It will allow to keep current type profile width and distinguish
>>>> bimorphic case from polimorphic.
>>> I like Tom's idea of mapping Reason_bimorphic to an unrelated reason, such as Reason_range_check.
>>> -- John
>