uncommon trap for athrow

[John Rose]

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.

[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