appa.htm

JAVA Developing Professional JavaApplets

<BR>
&nbsp;&nbsp;&nbsp;&nbsp;u2 attributes_count;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;attribute_info attributes[attribute_count];
<BR>
}</TT>
</BLOCKQUOTE>
<P>
Code attributes contain a private list of other attributes. Typically,
these are debugging lists, such as line number information. Now
that you've hit the code attribute, it's time to jump into the
virtual machine.
<H2><A NAME="TheVirtualMachine"><FONT SIZE=5 COLOR=#FF0000>The
Virtual Machine</FONT></A></H2>
<P>
The Java virtual machine interprets Java byte codes that are contained
in code attributes. The virtual machine is stack based. Most computer
architectures perform their operations on a mixture of memory
locations and registers. The Java virtual machine performs its
operations exclusively on a stack. This is done primarily to support
portability. No assumptions could be made about the size or number
of registers in a given CPU. Intel microprocessors are especially
limited in their register composition.
<H3><A NAME="Registers">Registers</A></H3>
<P>
The virtual machine does contain some registers, but these are
used for tracking the current state of the machine:
<UL>
<LI><TT>pc</TT> register points to
the next bytecode to execute
<LI><TT>vars</TT> register points
to the local variables for a method
<LI><TT>optop</TT> register points
to the operand stack
<LI><TT>frame</TT> register points
to the execution environment
</UL>
<P>
All these registers are 32 bits wide and point into separate storage
blocks. The blocks, however, can be allocated all at once because
the code attribute specifies the size of the operand stack, the
number of local variables, and the length of the bytecodes.
<H3><A NAME="OperandStack">Operand Stack</A></H3>
<P>
Most Java byte codes work on the operand stack. For instance,
to add two integers together, each integer is pushed onto the
operand stack. The addition operator removes the top two integers,
adds them, and places the result in its place back on the stack:
<BLOCKQUOTE>
<TT>..., 4, 5 -&gt; ..., 9<BR>
</TT>
</BLOCKQUOTE>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
The operand stack notation is used throughout the remainder of this appendix. The stack reads from left to right, with the stack top on the extreme right. Ellipses indicate indeterminate data buried on the stack. The arrow indicates an operation; the data to the right of the arrow represents the stack after the operation is performed.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
Each stack location is 32 bits wide. Long and doubles are 64 bits
wide, so they take up two stack locations.
<H2><A NAME="PrimitiveTypes"><FONT SIZE=5 COLOR=#FF0000>Primitive
Types</FONT></A></H2>
<P>
The virtual machine provides support for nine primitive types:
<UL>
<LI><TT>byte</TT>-single byte signed
2's complement
<LI><TT>short</TT>-2-byte signed 2's
complement
<LI><TT>int</TT>-4-byte signed 2's
complement
<LI><TT>long</TT>-8-byte signed 2's
complement
<LI><TT>float</TT>-4-byte IEEE 754
single precision
<LI><TT>double</TT>-8-byte IEEE 754
double precision
<LI><TT>char</TT>-2-byte unsigned
Unicode character
<LI><TT>object</TT>-4-byte reference
to a Java object
<LI><TT>returnAddress</TT>-4-byte
reference
</UL>
<P>
The virtual machine specification does not mandate the internal
format of object references. In Sun's implementation, object references
point to a Java handle consisting of two pointers. One points
to the method table for the class and the other points to the
object's instance data.
<H2><A NAME="LocalVariables"><FONT SIZE=5 COLOR=#FF0000>Local
Variables</FONT></A></H2>
<P>
Each code attribute specifies the size of the local variables.
A local variable is 32 bits wide, so long and double primitives
take up two variable slots. Unlike C, all method arguments appear
as local variables. The operand stack is reserved exclusively
for operations.
<H3><A NAME="TheVerifier">The Verifier</A></H3>
<P>
When a class is loaded, it is passed through a bytecode verifier
before it is executed. The verifier checks the internal consistency
of the class and the validity of the code. Java uses a late binding
scheme that puts the code at risk. In traditional languages, the
object linker binds all of the method calls and variable accesses
to specific addresses. In Java, the virtual machine doesn't perform
this service until the last possible moment. As a result, it is
possible for a called class to have changed since the original
class was compiled. Method names or their arguments may have been
altered, or the access levels may have been changed. One of the
verifier's jobs is to make sure that all external object references
are correct and allowed.
<P>
No assumptions can be made about the origin of bytecodes. A hostile
compiler could be used to create executable bytecodes that conform
to the class file format, but specify illegal codes.
<P>
The verifier uses a conservative four-pass verification algorithm
to check bytecodes.
<H4>Pass 1</H4>
<BLOCKQUOTE>
This pass reads in the class file and ensures that it is valid.
The magic number must be present and all the class data must be
present with no truncation or extra data after the end of the
class. Any recognized attributes must have the correct length
and the constant pool must not have any unrecognized entries.
</BLOCKQUOTE>
<H4>Pass 2</H4>
<BLOCKQUOTE>
The second pass involves validating class features other than
the bytecodes. All methods and fields must have a valid name and
signature and every class must have a super class. Signatures
are not actually checked, but they must appear valid. The next
pass is more specific.
</BLOCKQUOTE>
<H4>Pass 3</H4>
<BLOCKQUOTE>
This is the most complex pass because the bytecodes are validated.
The bytecodes are analyzed to make sure that they have the correct
type and number of arguments. In addition, a data-flow analysis
is performed to determine each path through the method. Each path
must arrive at a given point with the same stack size and types.
Each path must call methods with the proper arguments, and fields
must be modified with values of the appropriate type. Class accesses
are not checked in this pass. Only the return type of external
functions is verified.
</BLOCKQUOTE>
<BLOCKQUOTE>
Forcing all paths to arrive with the same stack and registers
can lead the verifier to fail some otherwise legitimate bytecodes.
This is a small price to pay for this high level of security.
</BLOCKQUOTE>
<H4>Pass 4</H4>
<BLOCKQUOTE>
This pass loads externally referenced classes and checks that
the method name and signatures match. It also validates that the
current class has access rights to the external class. After complete
validation, each instruction is replaced with a <TT>_quick</TT>
alternative. These <TT>_quick</TT>
bytecodes indicate that the class has been verified and need not
be checked again.
</BLOCKQUOTE>
<H3><A NAME="ExceptionHandling">Exception Handling</A></H3>
<P>
The <TT>pc</TT> register points to
the next bytecode to execute. Whenever an exception is thrown,
the method's exception table is searched for a handler. Each exception
table entry has this format:
<BLOCKQUOTE>
<TT>ExceptionItem<BR>
{<BR>
&nbsp;&nbsp;&nbsp;&nbsp;u2 start_pc;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;u2 end_pc;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;u2 handler_pc;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;u2 catch_type;<BR>
}</TT>
</BLOCKQUOTE>
<P>
If the <TT>pc</TT> register is within
the proper range and the thrown exception is the proper type,
the entry's handler code block is executed. If no handler is found,
the exception propagates up to the calling method. The procedure
repeats itself until either a valid handler is found or the program
exits.
<H3><A NAME="Bytecodes">Bytecodes</A></H3>
<P>
The bytecodes can be divided into 11 major categories:
<UL>
<LI>Pushing constants onto the stack
<LI><FONT COLOR=#000000>Moving local variable contents to and
from the stack</FONT>
<LI><FONT COLOR=#000000>Managing arrays</FONT>
<LI><FONT COLOR=#000000>Generic stack instructions (dup, swap,
pop &amp; nop)</FONT>
<LI><FONT COLOR=#000000>Arithmetic and logical instructions</FONT>
<LI><FONT COLOR=#000000>Conversion instructions</FONT>
<LI><FONT COLOR=#000000>Control transfer and function return</FONT>
<LI><FONT COLOR=#000000>Manipulating object fields</FONT>
<LI><FONT COLOR=#000000>Method invocation</FONT>
<LI><FONT COLOR=#000000>Miscellaneous operations</FONT>
<LI><FONT COLOR=#000000>Monitors</FONT>
</UL>
<P>
Each bytecode has a unique tag and is followed by a fixed number
of additional arguments. Notice that there is no way to work directly
with class fields or local variables. They must be moved to the
operand stack before any operations can be performed on the contents.
<P>
Generally, there are multiple formats for each individual operation.
The addition operation provides a good example. There are actually
four forms of addition: <TT>iadd</TT>,
<TT>ladd</TT>, <TT>fadd</TT>,
and <TT>dadd</TT>. Each type assumes
the top two stack items are of the correct format: integers, longs,
floats, or doubles.
<H4>Pushing Constants Onto the Stack</H4>
<P>
Java uses the following instructions for moving object data and
local variables to the operand stack:
<H5>Push One-Byte Signed Integer</H5>
<BLOCKQUOTE>
<TT>bipush=16 byte1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Stack:
... -&gt; ..., byte1</TT>
</BLOCKQUOTE>
<H5>Push Two-Byte Signed Integer</H5>
<BLOCKQUOTE>
<TT>sipush=17 byte1 byte2&nbsp;&nbsp;&nbsp;&nbsp;Stack:
... -&gt; ..., word1</TT>
</BLOCKQUOTE>
<H5>Push Item From the Constant Pool (8-bit index)</H5>
<BLOCKQUOTE>
<TT>ldc1=18 indexbyte1&nbsp;&nbsp;&nbsp;&nbsp;Stack:
... -&gt; ..., item</TT>
</BLOCKQUOTE>
<H5>Push Item from the Constant Pool (16-bit index)</H5>
<BLOCKQUOTE>
<TT>ldc2=19 indexbyte1 indexbyte2&nbsp;&nbsp;&nbsp;Stack:
... -&gt; ..., item</TT>
</BLOCKQUOTE>
<H5>Push Long or Double from Constant Pool (16-bit index)</H5>
<BLOCKQUOTE>
<TT>ldc2w=20 indexbyte1 indexbyte2&nbsp;&nbsp;&nbsp;Stack:
... -&gt; ..., word1, word2</TT>
</BLOCKQUOTE>
<H5>Push Null Object</H5>
<BLOCKQUOTE>
<TT>aconst_null=1&nbsp;&nbsp;&nbsp;&nbsp;Stack:
... -&gt; ..., null</TT>
</BLOCKQUOTE>
<H5>Push Integer Constant -1</H5>
<BLOCKQUOTE>
<TT>iconst_m1=2&nbsp;&nbsp;&nbsp;Stack: ...
-&gt; ..., -1</TT>
</BLOCKQUOTE>
<H5>Push Integer Constants</H5>
<BLOCKQUOTE>
<TT>iconst_0=3&nbsp;&nbsp;&nbsp;Stack: ...
-&gt; ..., 0<BR>
iconst_1=4&nbsp;&nbsp;&nbsp;Stack: ... -&gt; ..., 1<BR>
iconst_2=5&nbsp;&nbsp;&nbsp;Stack: ... -&gt; ..., 2<BR>
iconst_3=6&nbsp;&nbsp;&nbsp;Stack: ... -&gt; ..., 3<BR>
iconst_4=7&nbsp;&nbsp;&nbsp;Stack: ... -&gt; ..., 4<BR>
iconst_5=8&nbsp;&nbsp;&nbsp;Stack: ... -&gt; ..., 5</TT>
</BLOCKQUOTE>
<H5>Push Long Constant</H5>
<BLOCKQUOTE>
<TT>lconst_0=9&nbsp;&nbsp;&nbsp;Stack: ...
-&gt; ..., 0, 0<BR>
lconst_1=10&nbsp;&nbsp;Stack: ... -&gt; ..., 0, 1</TT>
</BLOCKQUOTE>
<H5>Push Float Constants</H5>
<BLOCKQUOTE>
<TT>fconst_0=11&nbsp;&nbsp;&nbsp;Stack: ...
-&gt; ..., 0<BR>
fconst_1=12&nbsp;&nbsp;&nbsp;Stack: ... -&gt; ..., 1<BR>
fconst_2=13&nbsp;&nbsp;&nbsp;Stack: ... -&gt; ..., 2</TT>
</BLOCKQUOTE>
<H5>Push Double Constants</H5>
<BLOCKQUOTE>
<TT>dconst_0=14&nbsp;&nbsp;&nbsp;Stack: ...
-&gt; ..., 0, 0<BR>
dconst_1=15&nbsp;&nbsp;&nbsp;Stack: ... -&gt; ..., 0, 1</TT>
</BLOCKQUOTE>
<H4>Accessing Local Variables</H4>
<P>
The most commonly referenced local variables are at the first
four offsets from the <TT>vars</TT>
register. Because of this, Java provides single byte instructions
to access these variables for both reading and writing. A two-byte
instruction is needed to reference variables greater than 4 deep.
The variable at location zero is the class pointer itself (the
<TT>this</TT> pointer).
<H5>Load Integer from Local Variable</H5>
<BLOCKQUOTE>
<TT>iload=21 vindex&nbsp;&nbsp;Stack: ...
-&gt; ..., contents of varaible at vars[vindex]<BR>
iload_o=26&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., contents of variable at vars[0]<BR>
iload_1=27&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., contents of variable at vars[1]<BR>
iload_2=28&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., contents of variable at vars[2]<BR>
iload_3=29&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., contents of variable at vars[3]</TT>
</BLOCKQUOTE>
<H5>Load Long Integer from Local Variable</H5>
<BLOCKQUOTE>
<TT>lload=22 vindex&nbsp;&nbsp;Stack: ..
-&gt; ..., word1, word2&nbsp;&nbsp;from vars[vindex] &amp; vars[vindex+1]
<BR>
lload_0=30&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: .. -&gt;
..., word1, word2&nbsp;&nbsp;from vars[0] &amp; vars[1]<BR>
lload_1=31&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: .. -&gt;
..., word1, word2&nbsp;&nbsp;from vars[1] &amp; vars[2]<BR>
lload_2=32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: .. -&gt;
..., word1, word2&nbsp;&nbsp;from vars[2] &amp; vars[3]<BR>
lload_3=33&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: .. -&gt;
..., word1, word2&nbsp;&nbsp;from vars[3] &amp; vars[4]</TT>
</BLOCKQUOTE>
<H5>Load Float from Local Variable</H5>
<BLOCKQUOTE>
<TT>fload=23 vindex&nbsp;&nbsp;Stack: ...
-&gt; ..., contents from vars[vindex]<BR>
fload_0=34&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., contents from vars[0]<BR>
fload_1=35&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., contents from vars[1]<BR>
fload_2=36&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., contents from vars[2]<BR>
fload_3=37&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., contents from vars[3]</TT>
</BLOCKQUOTE>
<H5>Load Double from Local Variable</H5>
<BLOCKQUOTE>
<TT>dload=24 vindex&nbsp;&nbsp;Stack: ...
-&gt; ..., word1, word2&nbsp;&nbsp;from vars[vindex] &amp; vars[vindex+1]
<BR>
dload_0=38&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., word1, word2&nbsp;&nbsp;from vars[0] &amp; vars[1]<BR>
dload_1=39&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., word1, word2&nbsp;&nbsp;from vars[1] &amp; vars[2]<BR>
dload_2=40&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stack: ... -&gt;
..., word1, word2&nbsp;&nbsp;from vars[2] &amp; vars[3]<BR>