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

[Tom Rodriguez]

>>> Tom would know better as he did the changes, but we changed the code so
>>> that C1 has the same unwinding mechanism as C2 does.  This makes the C1
>>> code a bit simpler.
>> 
>> Otherwise the unwind code has to do a call into the runtime to find out the nmethod frame_size so that it can take the frame off the stack properly.  I just didn't like doing that and never liked that C1 and C2 did these differently for no good reason so it seemed easiest to make it work the same.
> 
> 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.

>> 
>>> 
>>> Regarding performance, why do you think it affects performance
>>> negatively?
>> 
>> I don't see any reason that this should hurt performance, at least enough to matter.  The unwind path is changed to a jump to a tiny trampoline in the nmethod that adjusts sp and jumps to the unwind handler, so you don't go directly to the unwind handler but it's pretty minimal.  Are there are other code generation effects that would be expected?
> 
> Exception stack unwinding will be a bit slower, but I guess that doesn't matter at all.
> 
> 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 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.  We could simply inject the default exception handler into the exception table when we are building it in Compilation::generate_exception_handler_table.  Basically any table that doesn't end with a catch_all should dispatch to the default exception block.  It's a little ugly but I think it would work.  What do you think?

tom

> 
> Christian