Java bytecode is the form of instructions that the Java virtual machine executes.Each bytecodeopcodeis one byte in length, although some require parameters, resulting insome multi-byte instructions. Not all of the possible 256 opcodes areused. In fact, Sun Microsystems, the original creators ofthe Java programming language, the Java virtual machine and othercomponents of the Java Runtime Environment (JRE), have set aside 3values to be permanently unimplemented.[1]
Contents[hide] |
A Java programmer does not need tobe aware of or understand Java bytecode at all. However, as suggestedin the IBMdeveloperWorks journal, "Understanding bytecode and what bytecode islikely to be generated by a Javacompiler helps the Java programmer in the same way that knowledgeof assembler helps the C or C++programmer."[2].
As each byte has 256 potential values, there are 256 possibleopcodes. Of these, 0x00 through 0xca, 0xfe, and 0xff are assignedvalues. 0xba is unused for historical reasons. 0xca is reserved as abreakpoint instruction for debuggers and is not used by the language.Similarly, 0xfe and 0xff are not used by the language, and are reservedfor internal use by the virtual machine.
Instructions fall into a number of broad groups:
There are also a few instructions for a number of more specializedtasks such as exception throwing, synchronization, etc.
Many instructions have prefixes and/or suffixes referring to thetypes of operands they operate on. These are "i", "l", "s", "b", "c","f", "d", and "a", standing for, respectively, "integer", "long","short", "byte", "character", "float", "double", and "reference". Forexample, "iadd" will add two integers, while "dadd" will add twodoubles. The "const", "load", and "store" instructions may also take asuffix of the form "_n", where n is a number from 0-3 for"load" and "store". The maximum n for "const" differs by type.
The "const" instructions push a value of the specified type onto thestack. For example "iconst_5" will push an integer 5, while "dconst_1"will push a double 1. There is also an "aconst_null", which pushes"null". The n for the "load" and "store" instructions specifiesthe location in the variable table to load from or store to. The"aload_0" instruction pushes the object in variable 0 onto the stack(this is usually the "this" object). "istore_1" stores the integer onthe top of the stack into variable 1. For variables with higher numbersthe suffix is dropped and operators must be used.
The computational model of Java bytecode is that of a stack-oriented programminglanguage. For example, assembly code for an x86 processormight look like this:
add eax, edx
mov ecx, eax
This code would add two values and move the result to a differentlocation. Similar disassembled bytecode might look like this:
0 iload_1
1 iload_2
2 iadd
3 istore_3
Here, the two values to be added are pushed onto the stack, wherethey are retrieved by the addition instruction, summed, and the resultplaced back on the stack. The storage instruction then moves the topvalue of the stack into a variable location. The numbers in front of theinstructions simply represent the offset of each instruction from thebeginning of the method. This stack-oriented model extends to the objectoriented aspects of the language as well. A method call called"getName()", for example, may look like the following:
Method java.lang.String getName()
0 aload_0 // The "this" object is stored in location 0 of the variable table
1 getfield #5 <Field java.lang.String name>
// This instructon pops an object from the top of the stack, retrieves the specified
// field from it, and pushes the field onto the stack.
// In this example, the "name" field is the fifth field of the class.
4 areturn // Returns the object on top of the stack from the method.
Consider the following Java code:
outer:
for (int i = 2; i < 1000; i++)
{
for (int j = 2; j < i; j++)
{
if (i % j == 0)
continue outer;
}
System.out.println (i);
}
A Java compiler might translate the Java code above into byte code asfollows, assuming the above was put in a method:
0: iconst_2
1: istore_1
2: iload_1
3: sipush 1000
6: if_icmpge 44
9: iconst_2
10: istore_2
11: iload_2
12: iload_1
13: if_icmpge 31
16: iload_1
17: iload_2
18: irem
19: ifne 25
22: goto 38
25: iinc 2, 1
28: goto 11
31: getstatic #84; //Field java/lang/System.out:Ljava/io/PrintStream;
34: iload_1
35: invokevirtual #85; //Method java/io/PrintStream.println:(I)V
38: iinc 1, 1
41: goto 2
44: return
The most common language targeting Java Virtual Machine by producing Java bytecode isJava. Originally only one compiler existed, the javaccompiler from Sun Microsystems, which compiles Java source code to Java bytecode; butbecause all the specifications for Java bytecode are now available,other parties have supplied compilers that produce Java bytecode.Examples of other compilers include:
Some projects provide Java assemblers to enable writing Java bytecodeby hand. Assembler code may be also generated by machine, for exampleby compiler targeting Java virtual machine. NotableJava assemblers include:
Others have developed compilers, for different programming languages,in order to target the Java virtual machine, such as:
JavaFXcode is also compiled to Java bytecode.
Java bytecode is designed to be executed in a Java virtual machine. There areseveral virtual machines available today, both free and commercialproducts.
If executing Java bytecode in a Java virtual machine is notdesirable, a developer can also compile Java source code or Javabytecode directly to native machine code with tools such as the GNUCompiler for Java. Some ARM processors have the ability to executebytecode directly (see Jazelle).
The Java Virtual Machine has currently nobuilt-in support for dynamically typed languages, because theexisting JVM instruction set is statically typed - in the sense that methodcalls have their signatures type-checked at compile time, without amechanism to defer this decision to run time, or to choose the methoddispatch by an alternative approach.[5]
JSR 292 (Supporting DynamicallyTyped Languages on the JavaTM Platform) [6]propose to add a new invokedynamic instruction at the JVMlevel, to allow method invocation relying on dynamic type checking (instead of the existingstatically type-checked invokevirtual instruction). The Da Vinci Machine is a prototype virtual machineimplementation that hosts JVM extensions aimed at supporting dynamiclanguages.
 | The Wikibook Java Programming has a page on the topic of |
| |||||||||||||||||||||||||
