Request for reviews (M): 6614597: Performance variability in jvm2008 xml.validation
John.Rose at Sun.COM
Fri Jan 22 15:11:49 PST 2010
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.
More information about the hotspot-compiler-dev