Jump to content

Java bytecode

From Wikipedia, the free encyclopedia
(Redirected from JVM bytecode)

Java bytecode is the instruction set of the Java virtual machine (JVM), the language to which Java and other JVM-compatible source code is compiled.[1] Each instruction is represented by a single byte, hence the name bytecode, making it a compact form of data.[2]

Due to the nature of bytecode, a Java bytecode program is runnable on any machine with a compatible JVM; without the lengthy process of compiling from source code.

Java bytecode is used at runtime either interpreted by a JVM or compiled to machine code via just-in-time (JIT) compilation and run as a native application.

As Java bytecode is designed for a cross-platform compatibility and security, a Java bytecode application tends to run consistently across various hardware and software configurations.[3]

Relation to Java

[edit]

In general, a Java programmer does not need to understand Java bytecode or even be aware of it. 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."[4]

Instruction set architecture

[edit]

The bytecode comprises various instruction types, including data manipulation, control transfer, object creation and manipulation, and method invocation, all integral to Java's object-oriented programming model.[1]

The JVM is both a stack machine and a register machine. Each frame for a method call has an "operand stack" and an array of "local variables".[5]: 2.6  [2] The operand stack is used for operands to computations and for receiving the return value of a called method, while local variables serve the same purpose as registers and are also used to pass method arguments. The maximum size of the operand stack and local variable array, computed by the compiler, is part of the attributes of each method.[5]: 4.7.3  Each can be independently sized from 0 to 65535 values, where each value is 32 bits. long and double types, which are 64 bits, take up two consecutive local variables[5]: 2.6.1  (which need not be 64-bit aligned in the local variables array) or one value in the operand stack (but are counted as two units in the depth of the stack).[5]: 2.6.2 

Instruction set

[edit]

Each bytecode is composed of one byte that represents the opcode, along with zero or more bytes for operands.[5]: 2.11 

Of the 256 possible byte-long opcodes, as of 2015, 202 are in use (~79%), 51 are reserved for future use (~20%), and 3 instructions (~1%) are permanently reserved for JVM implementations to use.[5]: 6.2  Two of these (impdep1 and impdep2) are to provide traps for implementation-specific software and hardware, respectively. The third is used for debuggers to implement breakpoints.

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.[5]: 2.11.1  These are as follows:

Prefix/suffix Operand type
i integer
l long
s short
b byte
c character
f float
d double
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 (32 bit value) with the value 5 onto the stack, while dconst_1 will push a double (64 bit floating point value) with the value 1 onto the stack. There is also an aconst_null, which pushes a null reference. The n for the load and store instructions specifies the index in the local variable array to load from or store to. The aload_0 instruction pushes the object in local variable 0 onto the stack (this is usually the this object). istore_1 stores the integer on the top of the stack into local variable 1. For local variables beyond 3 the suffix is dropped and operands must be used.

Example

[edit]

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 bytecode 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

[edit]

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:

  • Eclipse compiler for Java (ECJ)
  • Jikes, compiles from Java to Java bytecode (developed by IBM, implemented in C++)
  • Espresso, compiles from Java to Java bytecode (Java 1.0 only)
  • GNU Compiler for Java (GCJ), compiles from Java to Java bytecode; it can also compile to native machine code and was part of the GNU Compiler Collection (GCC) up until version 6.

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 text descriptions for Java classes, written in a simple assembly-like syntax using Java virtual machine instruction set and generates a Java class file[6]
  • 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.[7]
  • Krakatau Bytecode Tools, currently contains three tools: a decompiler and disassembler for Java classfiles and an assembler to create classfiles.[8]
  • Lilac, an assembler and disassembler for the Java virtual machine.[9]

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

Execution

[edit]

There are several Java virtual machines available today to execute Java bytecode, both free and commercial products. If executing bytecode in a virtual machine is undesirable, a developer can also compile Java source code or bytecode directly to native machine code with tools such as the GNU Compiler for Java (GCJ). Some processors can execute Java bytecode natively. Such processors are termed Java processors.

Support for dynamic languages

[edit]

The Java virtual machine provides some support for dynamically typed languages. Most of the extant 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.[12]

JSR 292 (Supporting Dynamically Typed Languages on the Java Platform)[13] added a new invokedynamic instruction at the JVM level, to allow method invocation relying on dynamic type checking (instead of the extant 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

[edit]

References

[edit]
  1. ^ a b "Java Virtual Machine Specification". Oracle. Retrieved 14 November 2023.
  2. ^ a b Lindholm, Tim (2015). The Java Virtual Machine Specification. Oracle. ISBN 978-0133905908.
  3. ^ Arnold, Ken (1996). "The Java Programming Language". Sun Microsystems. 1 (1): 30–40.
  4. ^ "IBM Developer". developer.ibm.com. Retrieved 20 February 2006.
  5. ^ a b c d e f g Lindholm, Tim; Yellin, Frank; Bracha, Gilad; Buckley, Alex (13 February 2015). The Java Virtual Machine Specification (Java SE 8 ed.).
  6. ^ "Jasmin Home Page". jasmin.sourceforge.net. Retrieved 2 June 2024.
  7. ^ "Jamaica: The Java virtual machine (JVM) macro assembler". Retrieved 2 June 2024.
  8. ^ "Storyyeller/Krakatau". 1 June 2024. Retrieved 2 June 2024 – via GitHub.
  9. ^ "Lilac - a Java assembler". lilac.sourceforge.net. Retrieved 2 June 2024.
  10. ^ "FPC New Features 3.0.0 - Free Pascal wiki". wiki.freepascal.org. Retrieved 2 June 2024.
  11. ^ "FPC JVM - Free Pascal wiki". wiki.freepascal.org. Retrieved 2 June 2024.
  12. ^ Nutter, Charles (3 January 2007). "InvokeDynamic: Actually Useful?". Retrieved 25 January 2008.
  13. ^ "The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 292". www.jcp.org. Retrieved 2 June 2024.
[edit]