Java bytecode is the instruction set of theJava virtual machine (JVM), the language to whichJava and other JVM-compatiblesource code iscompiled.[1] Each instruction is represented by a singlebyte, hence the namebytecode, making it a compact form ofdata.[2]
Due to the nature of bytecode, a Java bytecodeprogram is runnable on any machine with a compatible JVM, without the lengthy process of compiling from source code.
Java bytecode is used atruntime eitherinterpreted by a JVM or compiled to machine code viajust-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 varioushardware andsoftware configurations.[3]
In general, a Javaprogrammer does not need to understand Java bytecode or even be aware of it. However, as suggested in theIBM developerWorks journal, "Understanding bytecode and what bytecode is likely to be generated by aJava compiler helps the Java programmer in the same way that knowledge ofassembly helps theC orC++ programmer."[4]
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 astack machine and aregister machine. Eachframe for a method call has an "operand stack" and an array of "local variables".[5]: 2.6 [2] The operand stack is used for passing operands to computations and for receiving the return value of a called method, while local variables serve the same purpose asregisters 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 anddouble 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
Eachbytecode is composed of one byte that represents theopcode, along with zero or more bytes for operands.[5]: 2.11
Of the 256 possible byte-longopcodes, as of 2015[update], 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 andimpdep2) 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:
aload_0,istore)ladd,fcmpl)i2b,d2i)new,putfield)swap,dup2)ifeq,goto)invokespecial,areturn)There are also a few instructions for a number of more specialized tasks such as exception throwing, synchronization, etc.
Many instructions haveprefixes 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, whiledadd will add two doubles. Theconst,load, andstore instructions may also take a suffix of the form_n, wheren is a number from 0–3 forload andstore. The maximumn forconst differs by type.
Theconst 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, whiledconst_1 will push a double (64 bit floating point value) with the value 1 onto the stack. There is also anaconst_null, which pushes anull reference. Then for theload andstore instructions specifies the index in the local variable array to load from or store to. Theaload_0 instruction pushes the object in local variable 0 onto the stack (this is usually thethis 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.
Consider the following Java code:
outer:for(inti=2;i<1000;i++){for(intj=2;j<i;j++){if(i%j==0)continueouter;}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_21:istore_12:iload_13:sipush10006:if_icmpge449:iconst_210:istore_211:iload_212:iload_113:if_icmpge3116:iload_117:iload_218:irem19:ifne2522:goto3825:iinc2,128:goto1131:getstatic#84;//Fieldjava/lang/System.out:Ljava/io/PrintStream;34:iload_135:invokevirtual#85; // Method java/io/PrintStream.println:(I)V38:iinc1,141:goto244:return
The most common language targetingJava virtual machine by producing Java bytecode is Java. Originally only one compiler existed, thejavac compiler fromSun Microsystems, which compilesJava 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:
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 aJava virtual machine. Notable Java assemblers include:
Others have developed compilers, for different programming languages, to target the Java virtual machine, such as:
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 theGNU Compiler for Java (GCJ). Some processors can execute Java bytecode natively. Such processors are termedJava processors.
TheJava virtual machine provides some support fordynamically typed languages. Most of the extant JVM instruction set isstatically typed - in the sense that method calls have their signatures type-checked atcompile time, without a mechanism to defer this decision torun 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 newinvokedynamic instruction at the JVM level, to allow method invocation relying on dynamictype checking (instead of the extant statically type-checkedinvokevirtual instruction). TheDa Vinci Machine is a prototype virtual machine implementation that hosts JVM extensions aimed at supporting dynamic languages. All JVMs supportingJSE 7 also include theinvokedynamic opcode.
| Platforms |
| _waving.svg) | |||||
|---|---|---|---|---|---|---|---|
| Technologies |
| ||||||
| History | |||||||
| JVM languages | |||||||
| Community |
| ||||||
