Sponsored Link •
|
Advertisement
|
As mentioned at the beginning of this chapter, all the subsystems, runtime data areas, and internal behaviors defined by the Java virtual machine specification are abstract. Designers aren't required to organize their implementations around "real" components that map closely to the abstract components of the specification. The abstract internal components and behaviors are merely a vocabulary with which the specification defines the required external behavior of any Java virtual machine implementation.
In other words, an implementation can be anything on the inside, so long as it behaves like a Java virtual machine on the outside. Implementations must be able to recognize Java class files and must adhere to the semantics of the Java code the class files contain. But otherwise, anything goes. How bytecodes are executed, how the runtime data areas are organized, how garbage collection is accomplished, how threads are implemented, how the bootstrap class loader finds classes, what native method interfaces are supported-- these are some of the many decisions left to implementation designers.
The flexibility of the specification gives designers the freedom to tailor their implementations to fit their circumstances. In some implementations, minimizing usage of resources may be critical. In other implementations, where resources are plentiful, maximizing performance may be the one and only goal.
By clearly marking the line between the external behavior and the internal implementation of a Java virtual machine, the specification preserves compatibility among all implementations while promoting innovation. Designers are encouraged to apply their talents and creativity towards building ever-better Java virtual machines.
The CD-ROM contains several simulation applets that serve as interactive illustrations for the material
presented in this book. The applet shown in Figure 5-14 simulates a Java virtual machine executing a few
bytecodes. You can run this applet by loading applets/EternalMath.html
from
the CD-ROM into any Java enabled web browser or applet viewer that supports JDK 1.0.
The instructions in the simulation represent the body of the doMathForever()
method of class Act
, shown previously in the "Instruction Set" section of this chapter.
This simulation shows the local variables and operand stack of the current frame, the pc register, and the
bytecodes in the method area. It also shows an optop register, which you can think of as part of the frame
data of this particular implementation of the Java virtual machine. The optop register always points to one
word beyond the top of the operand stack.
The applet has four buttons: Step, Reset, Run, and Stop. Each time you press the Step button, the Java
virtual machine simulator will execute the instruction pointed to by the pc register. Initially, the pc register
points to an iconst_0
instruction. The first time you press the Step button, therefore,
the virtual machine will execute iconst_0
. It will push a zero onto the stack and set
the pc register to point to the next instruction to execute. Subsequent presses of the Step button will execute
subsequent instructions and the pc register will lead the way. If you press the Run button, the simulation will
continue with no further coaxing on your part until you press the Stop button. To start the simulation over,
press the Reset button.
The value of each register (pc and optop) is shown two ways. The contents of each register, an integer offset from the beginning of either the method's bytecodes or the operand stack, is shown in an edit box. Also, a small arrow (either "pc>" or "optop>") indicates the location contained in the register.
In the simulation the operand stack is shown growing down the panel (up in memory offsets) as words are pushed onto it. The top of the stack recedes back up the panel as words are popped from it.
The doMathForever()
method has only one local variable,
i
, which sits at array position zero. The first two instructions,
iconst_0
and istore_0
initialize the local variable to zero. The
next instruction, iinc
, increments i
by one. This instruction
implements the i += 1
statement from doMathForever()
.
The next instruction, iload_0
, pushes the value of the local variable onto the operand
stack. iconst_2
pushes an int
2 onto the operand stack.
imul
pops the top two ints
from the operand stack, multiplies
them, and pushes the result. The istore_0
instruction pops the result of the multiply
and puts it into the local variable. The previous four instructions implement the i *= 2
statement from doMathForever()
. The last instruction, goto
,
sends the program counter back to the iinc
instruction. The goto
implements the for
(;;)
loop of
doMathForever()
.
With enough patience and clicks of the Step button (or a long enough run of the Run button), you can get an arithmetic overflow. When the Java virtual machine encounters such a condition, it just truncates, as is shown by this simulation. It does not throw any exceptions.
For each step of the simulation, a panel at the bottom of the applet contains an explanation of what the next instruction will do. Happy clicking.
The CD-ROM contains the source code examples from this chapter in the jvm
directory. The Eternal Math applet is contained in a web page on the CD-ROM in file
applets/EternalMath.html
. The source code for this applet is found alongside
its class files, in the applets/JVMSimulators
and
applets/JVMSimulators/COM/artima/jvmsim
directories.
For links to more information about the Java virtual machine, visit the resources page:
http://www.artima.com/insidejvm/resources/
Sponsored Links
|