In JDK-8275638, the fix was conservative, only pruning the stack if the method did not have exception handlers. However, we can do better. When creating an exception state, we can always prune the stack, even if the method has exception handlers. We only need to keep the stack if we need to re-execute the bytecode in the interpreter first, like for uncommon traps. The assert in GraphKit::combine_exception_states() that checks matching stack sizes can instead be changed to check for sp() == 0.

The rule about exception handlers applies to locals as well. If the method has no exception handlers, we can prune all the locals.

Further, we can do better with the "reexecute" flag that deoptimization uses and -XX:+VerifyStack checks. Currently this flag is driven by the bytecode through AbstractInterpreter::bytecode_should_reexecute(), with overrides for certain cases using set_should_reexecute(). This code is fragile because sync_jvms() can reset that flag, so PreserveReexecuteState must be used. Also, one bytecode may have more than one state for deoptimization. For example, we may have a null check using the before/reexecute state, and a normal safepoint and after state. It seems less error-prone to move towards more precise per-call setting of the reexecute flag rather than relying on per-bytecode defaults.