What determines the locals of a stackmap frame of a java bytecode try catch handler?

Question

Let's say we surround a few bytecode instructions with a try catch block, and the local types change in between the try catch block range (A previously local register used for an int type is now used for a reference type, inside of the TCB).

The handler of this try catch block can only have one frame (splitting is not allowed, java bytecode rules). But the problem is, if an exception is thrown before the local type change, the pointer frame would be different.

Depending on which local type is set when an exception is thrown in the TCB, the handler would have to have a different frame, but this is not possible in the java bytecode. Therefore my question: To which part in the TCB does the handler frame correspond? Will it use a "super-type" instead of choosing one (-> uninitalized)?

Answer 1

This is specified in JVMS §4.10.1.6:

An instruction satisfies an exception handler if the instructions's outgoing type state is ExcStackFrame, and the handler's target (the initial instruction of the handler code) is type safe assuming an incoming type state T. The type state T is derived from ExcStackFrame by replacing the operand stack with a stack whose sole element is the handler's exception class.

In other words, the outgoing state of all instructions guarded by the exception handler must have local variables assignable to the exception handler’s variables.

You (the code generator) decides how to solve this. Either, by declaring a variable having a common supertype of all possible types or by dropping the local variable, which is equivalent to setting the variable’s type to top, the verification type system’s root type that marks an unusable variable.

For ordinary Java code, it is impossible to use a variable declared in a try block within the associated catch block. Neither can you redeclare a variable to a different type. Therefore, it always boils down to dropping those variables and only have variables already existing before the guarded code.