uncommon trap for athrow

Tom Rodriguez Thomas.Rodriguez at Sun.COM
Fri Feb 12 14:57:04 PST 2010

On Feb 12, 2010, at 2:29 PM, Vladimir Kozlov wrote:

> Tom, I don see any issues. Only that the SSC_full_test subtype check code will be
> inline (not low probability) and larger then original.

In practice the test will never be more that an extra load unless the inheritance depth is enough to trigger the subtype search logic.  That doesn't seem like much extra code.

> Also the fast path has different probability for the check (0.9 vs 0.7).

I don't really think the probability will really play into the code generation that much since it's the exception paths.

> Did you run jvm2008 to see how many cases there?

It triggers in the compiler benchmarks but that's it.


> Thanks,
> Vladimir
> Tom Rodriguez wrote:
>> Sorry for the SWAN URL.  http://cr.openjdk.java.net/~never/6877221/src/share/vm/opto/doCall.cpp.udiff.html
>> tom
>> On Feb 12, 2010, at 12:46 PM, Tom Rodriguez wrote:
>>> 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

More information about the hotspot-compiler-dev mailing list