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

[Christian Wimmer]

>> That sounds reasonable, at first I thought that is a change that is  
>> related to invokedynamic.
>> When every exception dispatch goes through this exception handler,  
>> then this means that all of the "unwind" code (especially the  
>> unwind stub in the C1 runtime) can also go away?
>
> Not without rewriting our exception path.  The unwind call is  
> responsible for finding the pc in the caller to dispatch to and  
> there's no way to eliminate that unless we find some way to perform  
> both the lookup and unwind in one call.  It's also used on it's own  
> when we are throwing from a frame that we know doesn't have any  
> exception handlers.

OK, I get it now.

>> I'm more concerned about the compilation speed of C1. Back in the  
>> days, I optimized under the assumption that most of the blocks  
>> don't have exception edges. This is now no longer true, since  
>> nearly every block now has an exception edge to the synthetic  
>> exception handler. Did you see an impact on the compilation time?
>
> To be honest I didn't expect any so I didn't look.  I just ran some  
> ad hoc tests and it seems like it's a 10% compile speed hit, which  
> is pretty brutal.

I see a 6% to 12% compilation speed slowdown.

> I guess our choices are to back it out and go with the extra call in  
> the unwind path or to try to find some way to make the unwind  
> handler operate differently. Could we make the default exception  
> handler special in some way.  The default exception handler block  
> could be invisible to the rest of the system if it doesn't need to  
> perform any unlocking since there are no values live into it, at  
> least none that aren't bound.

I would prefer that the default exception handler of normal and  
synchronized methods are handled in the same way. The only difference  
is the unlock for synchronized methods,  but still the exception  
handler has no values flowing into it (because the unlock has not an  
instruction as the parameter, but always operates at lock 0).

So the code you just sent should work. But if the method already has a  
catch-all handler (such as the one for synchronized methods), then the  
re-throw of this is handled again by the new default handler,  
basically leading to another round of exception-dispatch in the same  
method.

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.

Christian