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

[Tom Rodriguez]

On Jan 21, 2010, at 9:16 PM, Vladimir Kozlov wrote:

> Thank you, John
> 
> The original code for Reason_bimorphic was suggested by Tom.
> And I did not pay much attention to the piggy-backing comment.
> I thought it means that we allow 4 (PerBytecodeTrapLimit) trap hits
> before recompilation as we do for class_check traps.
> 
> On 1/21/10 7:54 PM, John Rose wrote:
>> It looks as if you could adjust reason_recorded_per_bytecode_if_any to
>> treat Reason_bimorphic as piggy-backing on class_check, just as
>> div0_check is on null_check.
>> 
>> Did you consider this, but it didn't cause the right state changes? It
> 
> It is good idea. No, I did not consider it before.
> I will look how it works. There are other places where
> reason_recorded_per_bytecode_if_any() is used and I want to be sure
> it will not cause problems.

I don't see how this will work right.  The whole point of introducing a new reason was to get a separate counter to distinguish between the monomorphic and bimorphic predicted call cases.  Otherwise you can never make the mono to bi transition.  Maybe I don't understand what changing reason_recorded_per_bytecode_if_any in this way would do.  I'd prefer to have a per bytecode counter for bimorphic but we didn't have any left.

tom

> 
> Thanks,
> Vladimir
> 
> 
>> looks like it would work, and would let you avoid this new code:
>> 
>> 1381 if (reason == Reason_bimorphic) {
>> 1382 // This isn't recorded per bci because of MDO limitations
>> 1383 // but lets piggy back the invalidation on the
>> 1384 // Reason_class_check count.
>> 1385 uint prior_trap_count = trap_mdo->trap_count(Reason_bimorphic);
>> 1386 if (prior_trap_count >= (uint)PerBytecodeTrapLimit) {
>> 1387 make_not_entrant = true;
>> 
>> 1388 }
>> 
>> 
>> 
>> -- John