Java bytecode
Java bytecode is the instruction set of the Java virtual machine. Each bytecode is composed by one, or in some cases two, bytes that represent the instruction (opcode), along with zero or more bytes for passing parameters.
Of the 255 possible byte-long opcodes, as of 2015, 198 are in use (~77%), 54 are reserved for future use, and 3 instructions (~1%) are set aside as permanently unimplemented.[1]
The Java bytecode system does not directly support floating point operations beyond 32 bits, except indirectly via bytecodes that enable use of 64-bit and 80-bit intermediate IEEE floating point maths.
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]
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 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 operands must be used.
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 a compiler targeting a 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[3]
- 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.[4]
- Krakatau currently contains three tools: a decompiler and disassembler for Java classfiles and an assembler to create classfiles.[5]
- Lilac, an assembler and disassembler for the Java virtual machine.[6]
Others have developed compilers, for different programming languages, in order to target the Java virtual machine, such as:
- ColdFusion
- JRuby and Jython, two scripting languages based on Ruby and Python
- Groovy, a scripting language based on Java
- Scala, a type-safe general-purpose programming language supporting object-oriented and functional programming
- JGNAT and AppletMagic, compile from the Ada programming language to Java bytecode
- C to Java byte-code compilers
- Clojure, a functional, immutable, general-purpose programming language in the LISP family with a strong emphasis on concurrency
- MIDletPascal
- JavaFX Script code is also compiled to Java bytecode
- Kotlin
Execution
There are several 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.[7]
JSR 292 (Supporting Dynamically Typed Languages on the Java™ Platform)[8] 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 JSE 7 also include the invokedynamic
opcode.
See also
- Java bytecode instruction listings
- Java class file
- List of JVM languages
- Java backporting tools
- C to Java Virtual Machine compilers
- JStik
- Common Intermediate Language (CIL), Microsoft's rival to Java bytecode
- ObjectWeb ASM
References
- ↑ VM Spec - Reserved Opcodes
- ↑ Understanding bytecode makes you a better programmer
- ↑ Jasmin Home Page
- ↑ Jamaica: The Java Virtual Machine (JVM) Macro Assembler
- ↑ Krakatau Home Page
- ↑ Lilac Home Page
- ↑ Nutter, Charles (2007-01-03). "InvokeDynamic: Actually Useful?". Retrieved 2008-01-25.
- ↑ see JSR 292
External links
The Wikibook Java Programming has a page on the topic of: Java bytecode |
- Oracle's Java Virtual Machine Specification
- Programming Languages for the Java Virtual Machine
- Bytecode Visualizer – bytecode viewer and debugger (free Eclipse plugin)
- AdaptJ StackTrace – bytecode level debugging with a full control of the stack, the local variables, and the execution flow
- Java Class Unpacker – plugin for Total Commander, it lets open class files as compressed archives and see fields and methods as files. The bytecode can be viewed as text using F3
|