uncommon trap for athrow
Thomas.Rodriguez at Sun.COM
Fri Feb 12 12:46:33 PST 2010
I've been looking this again because there's a push for a fix and I've decided that removing athrow from can_rerun_bytecodes isn't really the right fix. It looks to me like the uncommon trap path is used for 2 reasons: if the klass mentioned in the handler is unloaded or if the klass has subklasses. There's a note there that now that subtype checks are fast we should emit a full subtype check instead of uncommon trapping. Fixing the code to do subtype check makes this test case work without deopt. It doesn't seem to me that the primary purpose of this uncommon trap is really to prune out exception paths but to deal with cases we don't handle. In practice it appears to be extremely rare that we even emit a trap.
Anyway, this is what I'm thinking:
Any gotchas that I should look out for with making this change? It's rare that it even emits this case with javac being the only benchmark test that really trigger its.
On Sep 10, 2009, at 12:02 PM, John Rose wrote:
> On Sep 10, 2009, at 11:30 AM, Tom Rodriguez wrote:
>> maybe the uncommon trap needs to have a proper trap count like other kinds of uncommon traps so that we could avoid it if it's hot. That might be better.
> I agree; if it gets hot we should make the extra paths.
> -- John
More information about the hotspot-compiler-dev