uncommon trap for athrow

[Vladimir Kozlov]

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.
Also the fast path has different probability for the check (0.9 vs 0.7).
Did you run jvm2008 to see how many cases there?

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
>