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

[John Rose]

On Jan 22, 2010, at 2:59 PM, Tom Rodriguez wrote:

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

It's a little better than the previous code, because at least the state changes are distinct now, because of the reasons.

There is also a small distinction between counter states.  If the per-nmethod counter for Reason_bimorphic is zero, then the per-bytecode count is disregarded, even though it is non-zero due to aliased Reason_class_check failures.  Note that maybe_prior_trap returned by query_update_method_data will be false even though the per-bytecode count (which is a single bit) is non-zero.

This allows one free bimorphism deopt per nmethod.  If this isn't enough, maybe we can downgrade one of the other one-bit counts to a per-nmethod count.

-- John