uncommon trap for athrow

[Tom Rodriguez]

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:

http://javaweb.sfbay.sun.com/~never/webrev/athrow/src/share/vm/opto/doCall.cpp.udiff.html

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.

tom

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