Jump to content

Java bytecode

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by A.amitkumar (talk | contribs) at 15:14, 28 June 2013 (Reverted edits by 123.236.199.182 (talk) to last revision by 98.248.43.179 (HG)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Java bytecode is the form of instructions that the Java virtual machine executes. Each bytecode opcode is one byte in length, although some require parameters, resulting in some multi-byte instructions. Not all of the possible 256 opcodes are used. 51 are reserved for future use. Beyond that, Sun Microsystems, the original developer of the Java platform, had set aside three values to be permanently unimplemented.[1]

Relation to Java

A Java programmer does not need to be aware of or understand Java bytecode at all. However, as suggested in the IBM developerWorks journal, "Understanding bytecode and what bytecode is likely to be generated by a Java compiler helps the Java programmer in the same way that knowledge of assembly helps the C or C++ programmer."[2] [3]

Instructions

See also: Java bytecode instruction listings

As each byte has 256 potential values, there are 256 possible opcodes. Of these, 0x00 through 0xca, 0xfe, and 0xff are assigned values. 0xca is reserved as a breakpoint instruction for debuggers and is not used by the language. Similarly, 0xfe and 0xff are not used by the language, and are reserved for internal use by the virtual machine.

Instructions fall into a number of broad groups:

  • Load and store (e.g. aload_0,istore)
  • Arithmetic and logic (e.g. ladd,fcmpl)
  • Type conversion (e.g. i2b,d2i)
  • Object creation and manipulation (new,putfield)
  • Operand stack management (e.g. swap,dup2)
  • Control transfer (e.g. ifeq,goto)
  • Method invocation and return (e.g. invokespecial,areturn)

There are also a few instructions for a number of more specialized tasks such as exception throwing, synchronization, etc.

Many instructions have prefixes and/or suffixes referring to the types of operands they operate on. These are as follows:

Prefix/Suffix Operand Type
i integer
l long
s short
b byte
c character
f float
d double
z boolean
a reference

For example, "iadd" will add two integers, while "dadd" will add two doubles. The "const", "load", and "store" instructions may also take a suffix 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 the stack. 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 specifies the location in the variable table[clarification needed] 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 on the top of the stack into variable 1. For variables with higher numbers the suffix is dropped and operators must be used .

Model of computation

The model of computation of Java bytecode is that of a stack-oriented programming language. For example, assembly code for an x86 processor might look like this:

 mov eax, byte [ebp-4]
 mov edx, byte [ebp-8]
 add eax, edx
 mov ecx, eax

This code would add two values and move the result to a different location. 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, where they are retrieved by the addition instruction, summed, and the result placed back on the stack. The storage instruction then moves the top value of the stack into a variable location. The numbers in front of the instructions simply represent the offset of each instruction from the beginning of the method. This stack-oriented model extends to the object oriented 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 instruction 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 corresponds to the fifth constant in the
                // constant pool of the class.
4 areturn       // Returns the object on top of the stack from the method.

Example

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 as follows, 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

Generation

The most common language targeting Java Virtual Machine by producing Java bytecode is Java. Originally only one compiler existed, the javac compiler from Sun Microsystems, which compiles Java source code to Java bytecode; but because all the specifications for Java bytecode are now available, other parties have supplied compilers that produce Java bytecode. Examples of other compilers include:

  • Jikes, compiles from Java to Java bytecode (developed by IBM, implemented in C++)
  • Espresso, compiles from Java to Java bytecode (Java 1.0 only)
  • GCJ, the GNU Compiler for Java, compiles from Java to Java bytecode; it is also able to compile to native machine code and is available as part of the GNU Compiler Collection (GCC).

Some projects provide Java assemblers to enable writing Java bytecode by hand. Assembly code may be also generated by machine, for example by compiler targeting Java virtual machine. Notable Java assemblers include:

  • Jasmin, takes textual descriptions for Java classes, written in a simple assembly-like syntax using Java Virtual Machine instruction set and generates a Java class file [4]
  • Jamaica, a macro assembly language for the Java virtual machine. Java syntax is used for class or interface definition. Method bodies are specified using bytecode instructions.[5]

Others have developed compilers, for different programming languages, in order to target the Java virtual machine, such as:

Execution

Java bytecode is designed to be executed in a Java virtual machine. There are several virtual machines available today, both free and commercial products.

If executing Java bytecode in a Java virtual machine is not desirable, a developer can also compile Java source code or Java bytecode directly to native machine code with tools such as the GNU Compiler for Java. Some processors can execute Java bytecode natively. Such processors are known as Java processors.

Support for dynamic languages

The Java Virtual Machine provides some support for dynamically typed languages. Most of the existing JVM instruction set is statically typed - in the sense that method calls have their signatures type-checked at compile time, without a mechanism to defer this decision to run time, or to choose the method dispatch by an alternative approach.[6]

JSR 292 (Supporting Dynamically Typed Languages on the Java™ Platform)[7] added a new invokedynamic instruction at the JVM level, to allow method invocation relying on dynamic type checking (instead of the existing statically type-checked invokevirtual instruction). The Da Vinci Machine is a prototype virtual machine implementation that hosts JVM extensions aimed at supporting dynamic languages. All JVMs supporting J2SE 7 also include the invokedynamic opcode.

See also

References

  1. ^ VM Spec - Reserved Opcodes
  2. ^ Understanding bytecode makes you a better programmer
  3. ^ A Formal Introduction to the Compilation of Java, Stephan Diehl, "Software - Practice and Experience", Vol. 28(3), pages 297-327, March 1998.
  4. ^ Jasmin Home Page
  5. ^ Jamaica: The Java Virtual Machine (JVM) Macro Assembler
  6. ^ Nutter, Charles (2007-01-03). "InvokeDynamic: Actually Useful?". Retrieved 2008-01-25.
  7. ^ see JSR 292