RFR: 8275638: GraphKit::combine_exception_states fails with "matching stack sizes" assert [v2]

Dean Long dlong at openjdk.java.net
Tue Nov 30 00:13:10 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

If we want to be conservative, then perhaps we should do a bailout if the stack size don't match.  Ignoring the stack in one place, but being careful to preserve it in others makes me think we are missing something.  For example, this troubling comment from Parse::catch_inline_exceptions():

911	  // Start executing from the given throw state.  (Keep its stack, for now.)

I think we need a followup RFE to clean this all up once and for all.

@vnkozlov, do we have someone who really understands what this exceptions code is doing in regards to stack sizes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6572


More information about the hotspot-compiler-dev mailing list