Compilation - Introduction to Compiler Construction in a Java World - page 16

FIGURE 1.10 Run-time stack frames in the JVM.

In both frames, locations are set aside for n formal parameters and m local variables;
n;m, or both may be 0. In the stack frame for a static method, these locations are allocated
at offsets beginning at 0. But in the invocation of an instance method, the instance itself, that
is, this , must be passed as an argument, so in an instance method's stack frame, location
0 is set aside for this , and parameters and local variables are allocated offset positions
starting at 1. The areas marked \computations" in the frames are memory locations set
aside for run-time stack computations within the method invocation.
While the compiler cannot predict how many stack frames will be pushed onto the stack
(that would be akin to solving the halting problem), it can compute the offsets of all formal
parameters and local variables, and compute how much space the method will need for its
computations, in each invocation.

1.4.9 codegen()
The purpose of codegen() is to generate JVM byte code from the AST, based on information
computed by preAnalyze() and analyze() . codegen() is invoked by Main 's sending the
codegen() message to the root of the AST, and codegen() recursively descends the AST,
generating byte code.
The format of a JVM class file is rather arcane. For this reason, we have implemented
a tool, CLEmitter (and its associated classes), to ease the generation of types (for example,
classes), members, and code. CLEmitter may be considered an abstraction of the JVM class
file; it hides many of the gory details. CLEmitter is described further in Appendix D.
Main creates

a new CLEmitter object. JClassDeclaration adds a new class,

using addClass() . JFieldDeclaration writes out the fields using addField() .