Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1
Tom Rodriguez
tom.rodriguez at oracle.com
Wed Mar 31 15:43:41 PDT 2010
>> 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?
http://cr.openjdk.java.net/~never/6939930 is version which hides the unwind handler from the IR at the cost of a little extra hand written assembly. It fixes the compile speed loss.
tom
>
> tom
>
>>
>> Christian
>
More information about the hotspot-compiler-dev
mailing list