uncommon trap for athrow

[Tom Rodriguez]

On Feb 12, 2010, at 2:37 PM, John Rose wrote:

> Yes, that should work.  That code was always half one thing and half another (half trap and half branch).  This is a good cleanup.
> 
> It's possible that the trapping behavior helps (as I said earlier) by removing paths from the machine-level CFG.  This would be in the case where the handler has never been executed (the common case), not when it is in active use.  We could consider building some logic complementary to 'treat_throw_as_hot' in graphKit.cpp:  A suitable 'treat_handler_as_hot' condition, when true, would route control flow from every call site, but the normal code shape would be a trap.

I don't really think this changes the number of edges in the graph.  Unless we emit an uncommon trap we produce an edge for every exception handler, either as an inline test or as a CatchProj off the rethrow call.  The oddity in the case that created the bug report was that the bytecode was an athrow which is rerunnable so we put in the uncommon trap.  Emitting the trap in general is rare, (<< 1%) and I think that if it became hot we'd really want to recompile it instead of trapping every time.  With my change the existing trap really devolves into a Reason_unloaded trap though it's using Action_none which isn't so great if the path becomes frequent.  We might simply remove it since we generate an uncommon trap in catch_call_exceptions for unloaded classes, though I wouldn't want to do that as part of this change since this is likely to be backported.

treat_handler_as_hot is an interesting idea.  We could consider profiling exception dispatch to drive logic like that.  However, I'd want some measurable improvement from such a change before we add yet another reason to throw out code and regenerate it.

tom

> 
> [Taking a careful look at 'catch_inline_exceptions'...]  I don't think the traps appear much in compiled code.  As you say, they are used for unloaded classes (which we don't much care about) and for non-exact catch types.  But the latter case happens only if the predicate 'remaining == 1' fails to pick off the common case of a single catch type.  So maybe the traps have always been rare, in which case it's OK to eliminate all of them.
> 
> -- John
> 
> On Feb 12, 2010, at 1:04 PM, Tom Rodriguez wrote:
> 
>> http://cr.openjdk.java.net/~never/6877221/src/share/vm/opto/doCall.cpp.udiff.html
>