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

[Christian Wimmer]

>> 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