RFR: 8275638: GraphKit::combine_exception_states fails with "matching stack sizes" assert [v2]
Dean Long
dlong at openjdk.java.net
Sat Nov 27 23:36:13 UTC 2021
On Fri, 26 Nov 2021 10:27:48 GMT, Roland Westrelin <roland at openjdk.org> wrote:
>> Root cause is identical to 8273165 AFIU: late inline of a virtual call
>> can throw from 2 different paths (null check and the call
>> itself). That breaks because the logic for exceptions expects the
>> stack for all paths that throw exceptions to have the same stack size.
>>
>> AFAIU, the stack doesn't matter exception handling: either the
>> exception is caught by a exception handler and then the stack is
>> popped and the exception is pushed or, the exception is rethrown to
>> the caller in which case the current stack is also popped (that is the
>> jvm state for the current method). As a consequence the fix I propose
>> is to ignore the stack in GraphKit::combine_exception_states().
>>
>> AFAIU, the same fix would work for 8273165 but I left the current work
>> around as is: not sure if we want to be conservative for now or not
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>
> make test runnable with release build
The existing code is confusing to me. Are these exception states only used when we are actually throwing an exception, or can do they affect the state when deoptimizing? Why does GraphKit::add_exception_state() have a comment about arguments and compares stacks? Why doesn't GraphKit::make_exception_state() just reset the stack using push_ex_oop() instead of preserving the stack wtih set_saved_ex_oop()? (The names for these two functions are terrible, because "push_ex_oop" resets the stack first and "set_saved_ex_oop" does not...)
-------------
PR: https://git.openjdk.java.net/jdk/pull/6572
More information about the hotspot-compiler-dev
mailing list