This is the class defining a runtime object. Such an object serves as the common execution environment context shared by Instructions being executed. It encapsulates a state of comptutation that is effected by each instruction as it is executed in its context.
A Runtime object consists of attributes and structures that together define a state of computation, and methods that are used by instructions to effect this state as they are executed. Thus, each instruction class defines an execute(Runtime) method that specifies its operational semantics as a state transformation of its given runtime context.
Initiating execution of a Runtime object consists of setting its code array to a given instruction sequence, setting its instruction pointer _ip to its code's first instruction and repeatedly calling execute(this) on whatever instruction is currently at address _ip in the current code array. The final state is reached when a flag indicating that it is so is set to true. Each instruction is responsible for appropriately setting the next state according to its semantics, including saving and restoring states, and (re)setting the code array and the various runtime registers pointing into the state's structures.
Runtime states encapsulated by objects in this class are essentially
those of a stack automaton, specifically conceived to support the
computations of a higher-order functional language with lexical closures
- i.e., a 
-calculus machine - extended to support
additional features - e.g., assignment side-effects, objects,
automatic currying... As such it may viewed as an optimized variant of
Peter Landin's SECD machine [4]--in the same spirit as Luca
Cardelli's Functional Abstract Machine (FAM) [1], although our
design is quite different from Cardelli's in its structure and
operations.
Because this is a Java implementation, in order to avoid the space and performance overhead of being confined to boxed values for primitive type computations, three concurrent sets of structures are maintained: in addition to those needed for boxed (Java object) values, two extra ones are used to support unboxed integer and floating-point values, respectively. The runtime operations performed by instructions on a Runtime object are guaranteed to be type-safe in that each state is always such as it must be expected for the correct accessing and setting of values. Such a guarantee must be (and is!) provided by the TypeChecker and the Sanitizer, which ascertain all the conditions that must be met prior to having a Compiler proceed to generating instructions which will safely act on the appropriate stacks and environments of the correct sort (integer, floating-point, or object).