Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1

[Tom Rodriguez]

http://cr.openjdk.java.net/~never/6939930 is a full solution.

6939930: exception unwind changes in 6919934 hurts compilation speed
Reviewed-by:

The fix 6919934 created a synthetic handler that was used to unwind
the frame during exception dispatch but the addition of this handler
slowed down compilation significantly.  Additionally it increased the
size of the nmethod by about 15% because of the extra exception
handler entries.  This change moves all the unwind logic down into the
assembler and adds a field in the nmethod which points at the unwind
handler.  This removes both the speed and space penalty.  The new
assembly unwind code is slightly tighter than what we used to emit.  I
also simplified the unwind LIR op slightly and separated it out.  It
also dispatches directly to the new unwind handler instead of
performing the unwind itself.

tom

On Mar 31, 2010, at 4:56 PM, Christian Wimmer wrote:

>>> A unified solution could be to always keep the synthetic exception handler, but don't generate all the unnecessary exception edges. Instead, it should be enough to just link it once from the the entry block (so that the exception handler is considered reachable). The entry point of this handler is then again remembered and faked into all exception handler tables.
>> 
>> I played a little bit with something like that but getting it properly hooked up seemed problematic.  I didn't try simply hooking it off the .  I do like the idea of a unified solution.  That's really what I was trying to get with the original changes.  Where do you think I would hook that up?  I'd have to do it at after parsing all the blocks wouldn't I?  Otherwise I assume that xhandler would propagate to following blocks.  Maybe hook it up just before the fill_sync_handler?
> 
> Yes, after IR construction would be the best place to hook it up. The only tricky thing is to not register the default exception handler as an exception handler of itself.
> 
> Another idea: put the unlocking code for synchronized methods also in the special exception handling code that you sent. That way, we have no synthetic exception handler at all in the IR. In some sense, that is going back to the state before we introduced the synthetic exception handler, but this time the locking and unlocking for normal method entries and exits of course remains explicit in the IR.
> 
> In any case, it is no longer legal to unwind directly at a throw instruction where exception_handlers()->length() == 0
> 
> Christian
>