1*0c56280aSSorin Basca<?xml version="1.0"?> 2*0c56280aSSorin Basca<!-- 3*0c56280aSSorin Basca * Licensed to the Apache Software Foundation (ASF) under one 4*0c56280aSSorin Basca * or more contributor license agreements. See the NOTICE file 5*0c56280aSSorin Basca * distributed with this work for additional information 6*0c56280aSSorin Basca * regarding copyright ownership. The ASF licenses this file 7*0c56280aSSorin Basca * to you under the Apache License, Version 2.0 (the 8*0c56280aSSorin Basca * "License"); you may not use this file except in compliance 9*0c56280aSSorin Basca * with the License. You may obtain a copy of the License at 10*0c56280aSSorin Basca * 11*0c56280aSSorin Basca * http://www.apache.org/licenses/LICENSE-2.0 12*0c56280aSSorin Basca * 13*0c56280aSSorin Basca * Unless required by applicable law or agreed to in writing, 14*0c56280aSSorin Basca * software distributed under the License is distributed on an 15*0c56280aSSorin Basca * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 16*0c56280aSSorin Basca * KIND, either express or implied. See the License for the 17*0c56280aSSorin Basca * specific language governing permissions and limitations 18*0c56280aSSorin Basca * under the License. 19*0c56280aSSorin Basca--> 20*0c56280aSSorin Basca<document> 21*0c56280aSSorin Basca <properties> 22*0c56280aSSorin Basca <title>The Java Virtual Machine</title> 23*0c56280aSSorin Basca </properties> 24*0c56280aSSorin Basca 25*0c56280aSSorin Basca <body> 26*0c56280aSSorin Basca <section name="The Java Virtual Machine"> 27*0c56280aSSorin Basca <p> 28*0c56280aSSorin Basca Readers already familiar with the Java Virtual Machine and the 29*0c56280aSSorin Basca Java class file format may want to skip this section and proceed 30*0c56280aSSorin Basca with <a href="bcel-api.html">section 3</a>. 31*0c56280aSSorin Basca </p> 32*0c56280aSSorin Basca 33*0c56280aSSorin Basca <p> 34*0c56280aSSorin Basca Programs written in the Java language are compiled into a portable 35*0c56280aSSorin Basca binary format called <em>byte code</em>. Every class is 36*0c56280aSSorin Basca represented by a single class file containing class related data 37*0c56280aSSorin Basca and byte code instructions. These files are loaded dynamically 38*0c56280aSSorin Basca into an interpreter (<a 39*0c56280aSSorin Basca href="http://docs.oracle.com/javase/specs/">Java 40*0c56280aSSorin Basca Virtual Machine</a>, aka. JVM) and executed. 41*0c56280aSSorin Basca </p> 42*0c56280aSSorin Basca 43*0c56280aSSorin Basca <p> 44*0c56280aSSorin Basca <a href="#Figure 1">Figure 1</a> illustrates the procedure of 45*0c56280aSSorin Basca compiling and executing a Java class: The source file 46*0c56280aSSorin Basca (<tt>HelloWorld.java</tt>) is compiled into a Java class file 47*0c56280aSSorin Basca (<tt>HelloWorld.class</tt>), loaded by the byte code interpreter 48*0c56280aSSorin Basca and executed. In order to implement additional features, 49*0c56280aSSorin Basca researchers may want to transform class files (drawn with bold 50*0c56280aSSorin Basca lines) before they get actually executed. This application area 51*0c56280aSSorin Basca is one of the main issues of this article. 52*0c56280aSSorin Basca </p> 53*0c56280aSSorin Basca 54*0c56280aSSorin Basca <p align="center"> 55*0c56280aSSorin Basca <a name="Figure 1"> 56*0c56280aSSorin Basca <img src="../images/jvm.gif"/> 57*0c56280aSSorin Basca <br/> 58*0c56280aSSorin Basca Figure 1: Compilation and execution of Java classes</a> 59*0c56280aSSorin Basca </p> 60*0c56280aSSorin Basca 61*0c56280aSSorin Basca <p> 62*0c56280aSSorin Basca Note that the use of the general term "Java" implies in fact two 63*0c56280aSSorin Basca meanings: on the one hand, Java as a programming language, on the 64*0c56280aSSorin Basca other hand, the Java Virtual Machine, which is not necessarily 65*0c56280aSSorin Basca targeted by the Java language exclusively, but may be used by <a 66*0c56280aSSorin Basca href="http://www.robert-tolksdorf.de/vmlanguages.html">other 67*0c56280aSSorin Basca languages</a> as well. We assume the reader to be familiar with 68*0c56280aSSorin Basca the Java language and to have a general understanding of the 69*0c56280aSSorin Basca Virtual Machine. 70*0c56280aSSorin Basca </p> 71*0c56280aSSorin Basca 72*0c56280aSSorin Basca <subsection name="Java class file format"> 73*0c56280aSSorin Basca <p> 74*0c56280aSSorin Basca Giving a full overview of the design issues of the Java class file 75*0c56280aSSorin Basca format and the associated byte code instructions is beyond the 76*0c56280aSSorin Basca scope of this paper. We will just give a brief introduction 77*0c56280aSSorin Basca covering the details that are necessary for understanding the rest 78*0c56280aSSorin Basca of this paper. The format of class files and the byte code 79*0c56280aSSorin Basca instruction set are described in more detail in the <a 80*0c56280aSSorin Basca href="http://docs.oracle.com/javase/specs/">Java 81*0c56280aSSorin Basca Virtual Machine Specification</a>. Especially, we will not deal 82*0c56280aSSorin Basca with the security constraints that the Java Virtual Machine has to 83*0c56280aSSorin Basca check at run-time, i.e. the byte code verifier. 84*0c56280aSSorin Basca </p> 85*0c56280aSSorin Basca 86*0c56280aSSorin Basca <p> 87*0c56280aSSorin Basca <a href="#Figure 2">Figure 2</a> shows a simplified example of the 88*0c56280aSSorin Basca contents of a Java class file: It starts with a header containing 89*0c56280aSSorin Basca a "magic number" (<tt>0xCAFEBABE</tt>) and the version number, 90*0c56280aSSorin Basca followed by the <em>constant pool</em>, which can be roughly 91*0c56280aSSorin Basca thought of as the text segment of an executable, the <em>access 92*0c56280aSSorin Basca rights</em> of the class encoded by a bit mask, a list of 93*0c56280aSSorin Basca interfaces implemented by the class, lists containing the fields 94*0c56280aSSorin Basca and methods of the class, and finally the <em>class 95*0c56280aSSorin Basca attributes</em>, e.g., the <tt>SourceFile</tt> attribute telling 96*0c56280aSSorin Basca the name of the source file. Attributes are a way of putting 97*0c56280aSSorin Basca additional, user-defined information into class file data 98*0c56280aSSorin Basca structures. For example, a custom class loader may evaluate such 99*0c56280aSSorin Basca attribute data in order to perform its transformations. The JVM 100*0c56280aSSorin Basca specification declares that unknown, i.e., user-defined attributes 101*0c56280aSSorin Basca must be ignored by any Virtual Machine implementation. 102*0c56280aSSorin Basca </p> 103*0c56280aSSorin Basca 104*0c56280aSSorin Basca <p align="center"> 105*0c56280aSSorin Basca <a name="Figure 2"> 106*0c56280aSSorin Basca <img src="../images/classfile.gif"/> 107*0c56280aSSorin Basca <br/> 108*0c56280aSSorin Basca Figure 2: Java class file format</a> 109*0c56280aSSorin Basca </p> 110*0c56280aSSorin Basca 111*0c56280aSSorin Basca <p> 112*0c56280aSSorin Basca Because all of the information needed to dynamically resolve the 113*0c56280aSSorin Basca symbolic references to classes, fields and methods at run-time is 114*0c56280aSSorin Basca coded with string constants, the constant pool contains in fact 115*0c56280aSSorin Basca the largest portion of an average class file, approximately 116*0c56280aSSorin Basca 60%. In fact, this makes the constant pool an easy target for code 117*0c56280aSSorin Basca manipulation issues. The byte code instructions themselves just 118*0c56280aSSorin Basca make up 12%. 119*0c56280aSSorin Basca </p> 120*0c56280aSSorin Basca 121*0c56280aSSorin Basca <p> 122*0c56280aSSorin Basca The right upper box shows a "zoomed" excerpt of the constant pool, 123*0c56280aSSorin Basca while the rounded box below depicts some instructions that are 124*0c56280aSSorin Basca contained within a method of the example class. These 125*0c56280aSSorin Basca instructions represent the straightforward translation of the 126*0c56280aSSorin Basca well-known statement: 127*0c56280aSSorin Basca </p> 128*0c56280aSSorin Basca 129*0c56280aSSorin Basca <p align="center"> 130*0c56280aSSorin Basca <source>System.out.println("Hello, world");</source> 131*0c56280aSSorin Basca </p> 132*0c56280aSSorin Basca 133*0c56280aSSorin Basca <p> 134*0c56280aSSorin Basca The first instruction loads the contents of the field <tt>out</tt> 135*0c56280aSSorin Basca of class <tt>java.lang.System</tt> onto the operand stack. This is 136*0c56280aSSorin Basca an instance of the class <tt>java.io.PrintStream</tt>. The 137*0c56280aSSorin Basca <tt>ldc</tt> ("Load constant") pushes a reference to the string 138*0c56280aSSorin Basca "Hello world" on the stack. The next instruction invokes the 139*0c56280aSSorin Basca instance method <tt>println</tt> which takes both values as 140*0c56280aSSorin Basca parameters (instance methods always implicitly take an instance 141*0c56280aSSorin Basca reference as their first argument). 142*0c56280aSSorin Basca </p> 143*0c56280aSSorin Basca 144*0c56280aSSorin Basca <p> 145*0c56280aSSorin Basca Instructions, other data structures within the class file and 146*0c56280aSSorin Basca constants themselves may refer to constants in the constant pool. 147*0c56280aSSorin Basca Such references are implemented via fixed indexes encoded directly 148*0c56280aSSorin Basca into the instructions. This is illustrated for some items of the 149*0c56280aSSorin Basca figure emphasized with a surrounding box. 150*0c56280aSSorin Basca </p> 151*0c56280aSSorin Basca 152*0c56280aSSorin Basca <p> 153*0c56280aSSorin Basca For example, the <tt>invokevirtual</tt> instruction refers to a 154*0c56280aSSorin Basca <tt>MethodRef</tt> constant that contains information about the 155*0c56280aSSorin Basca name of the called method, the signature (i.e., the encoded 156*0c56280aSSorin Basca argument and return types), and to which class the method belongs. 157*0c56280aSSorin Basca In fact, as emphasized by the boxed value, the <tt>MethodRef</tt> 158*0c56280aSSorin Basca constant itself just refers to other entries holding the real 159*0c56280aSSorin Basca data, e.g., it refers to a <tt>ConstantClass</tt> entry containing 160*0c56280aSSorin Basca a symbolic reference to the class <tt>java.io.PrintStream</tt>. 161*0c56280aSSorin Basca To keep the class file compact, such constants are typically 162*0c56280aSSorin Basca shared by different instructions and other constant pool 163*0c56280aSSorin Basca entries. Similarly, a field is represented by a <tt>Fieldref</tt> 164*0c56280aSSorin Basca constant that includes information about the name, the type and 165*0c56280aSSorin Basca the containing class of the field. 166*0c56280aSSorin Basca </p> 167*0c56280aSSorin Basca 168*0c56280aSSorin Basca <p> 169*0c56280aSSorin Basca The constant pool basically holds the following types of 170*0c56280aSSorin Basca constants: References to methods, fields and classes, strings, 171*0c56280aSSorin Basca integers, floats, longs, and doubles. 172*0c56280aSSorin Basca </p> 173*0c56280aSSorin Basca 174*0c56280aSSorin Basca </subsection> 175*0c56280aSSorin Basca 176*0c56280aSSorin Basca <subsection name="Byte code instruction set"> 177*0c56280aSSorin Basca <p> 178*0c56280aSSorin Basca The JVM is a stack-oriented interpreter that creates a local stack 179*0c56280aSSorin Basca frame of fixed size for every method invocation. The size of the 180*0c56280aSSorin Basca local stack has to be computed by the compiler. Values may also be 181*0c56280aSSorin Basca stored intermediately in a frame area containing <em>local 182*0c56280aSSorin Basca variables</em> which can be used like a set of registers. These 183*0c56280aSSorin Basca local variables are numbered from 0 to 65535, i.e., you have a 184*0c56280aSSorin Basca maximum of 65536 of local variables per method. The stack frames 185*0c56280aSSorin Basca of caller and callee method are overlapping, i.e., the caller 186*0c56280aSSorin Basca pushes arguments onto the operand stack and the called method 187*0c56280aSSorin Basca receives them in local variables. 188*0c56280aSSorin Basca </p> 189*0c56280aSSorin Basca 190*0c56280aSSorin Basca <p> 191*0c56280aSSorin Basca The byte code instruction set currently consists of 212 192*0c56280aSSorin Basca instructions, 44 opcodes are marked as reserved and may be used 193*0c56280aSSorin Basca for future extensions or intermediate optimizations within the 194*0c56280aSSorin Basca Virtual Machine. The instruction set can be roughly grouped as 195*0c56280aSSorin Basca follows: 196*0c56280aSSorin Basca </p> 197*0c56280aSSorin Basca 198*0c56280aSSorin Basca <p> 199*0c56280aSSorin Basca <b>Stack operations:</b> Constants can be pushed onto the stack 200*0c56280aSSorin Basca either by loading them from the constant pool with the 201*0c56280aSSorin Basca <tt>ldc</tt> instruction or with special "short-cut" 202*0c56280aSSorin Basca instructions where the operand is encoded into the instructions, 203*0c56280aSSorin Basca e.g., <tt>iconst_0</tt> or <tt>bipush</tt> (push byte value). 204*0c56280aSSorin Basca </p> 205*0c56280aSSorin Basca 206*0c56280aSSorin Basca <p> 207*0c56280aSSorin Basca <b>Arithmetic operations:</b> The instruction set of the Java 208*0c56280aSSorin Basca Virtual Machine distinguishes its operand types using different 209*0c56280aSSorin Basca instructions to operate on values of specific type. Arithmetic 210*0c56280aSSorin Basca operations starting with <tt>i</tt>, for example, denote an 211*0c56280aSSorin Basca integer operation. E.g., <tt>iadd</tt> that adds two integers 212*0c56280aSSorin Basca and pushes the result back on the stack. The Java types 213*0c56280aSSorin Basca <tt>boolean</tt>, <tt>byte</tt>, <tt>short</tt>, and 214*0c56280aSSorin Basca <tt>char</tt> are handled as integers by the JVM. 215*0c56280aSSorin Basca </p> 216*0c56280aSSorin Basca 217*0c56280aSSorin Basca <p> 218*0c56280aSSorin Basca <b>Control flow:</b> There are branch instructions like 219*0c56280aSSorin Basca <tt>goto</tt>, and <tt>if_icmpeq</tt>, which compares two integers 220*0c56280aSSorin Basca for equality. There is also a <tt>jsr</tt> (jump to sub-routine) 221*0c56280aSSorin Basca and <tt>ret</tt> pair of instructions that is used to implement 222*0c56280aSSorin Basca the <tt>finally</tt> clause of <tt>try-catch</tt> blocks. 223*0c56280aSSorin Basca Exceptions may be thrown with the <tt>athrow</tt> instruction. 224*0c56280aSSorin Basca Branch targets are coded as offsets from the current byte code 225*0c56280aSSorin Basca position, i.e., with an integer number. 226*0c56280aSSorin Basca </p> 227*0c56280aSSorin Basca 228*0c56280aSSorin Basca <p> 229*0c56280aSSorin Basca <b>Load and store operations</b> for local variables like 230*0c56280aSSorin Basca <tt>iload</tt> and <tt>istore</tt>. There are also array 231*0c56280aSSorin Basca operations like <tt>iastore</tt> which stores an integer value 232*0c56280aSSorin Basca into an array. 233*0c56280aSSorin Basca </p> 234*0c56280aSSorin Basca 235*0c56280aSSorin Basca <p> 236*0c56280aSSorin Basca <b>Field access:</b> The value of an instance field may be 237*0c56280aSSorin Basca retrieved with <tt>getfield</tt> and written with 238*0c56280aSSorin Basca <tt>putfield</tt>. For static fields, there are 239*0c56280aSSorin Basca <tt>getstatic</tt> and <tt>putstatic</tt> counterparts. 240*0c56280aSSorin Basca </p> 241*0c56280aSSorin Basca 242*0c56280aSSorin Basca <p> 243*0c56280aSSorin Basca <b>Method invocation:</b> Static Methods may either be called via 244*0c56280aSSorin Basca <tt>invokestatic</tt> or be bound virtually with the 245*0c56280aSSorin Basca <tt>invokevirtual</tt> instruction. Super class methods and 246*0c56280aSSorin Basca private methods are invoked with <tt>invokespecial</tt>. A 247*0c56280aSSorin Basca special case are interface methods which are invoked with 248*0c56280aSSorin Basca <tt>invokeinterface</tt>. 249*0c56280aSSorin Basca </p> 250*0c56280aSSorin Basca 251*0c56280aSSorin Basca <p> 252*0c56280aSSorin Basca <b>Object allocation:</b> Class instances are allocated with the 253*0c56280aSSorin Basca <tt>new</tt> instruction, arrays of basic type like 254*0c56280aSSorin Basca <tt>int[]</tt> with <tt>newarray</tt>, arrays of references like 255*0c56280aSSorin Basca <tt>String[][]</tt> with <tt>anewarray</tt> or 256*0c56280aSSorin Basca <tt>multianewarray</tt>. 257*0c56280aSSorin Basca </p> 258*0c56280aSSorin Basca 259*0c56280aSSorin Basca <p> 260*0c56280aSSorin Basca <b>Conversion and type checking:</b> For stack operands of basic 261*0c56280aSSorin Basca type there exist casting operations like <tt>f2i</tt> which 262*0c56280aSSorin Basca converts a float value into an integer. The validity of a type 263*0c56280aSSorin Basca cast may be checked with <tt>checkcast</tt> and the 264*0c56280aSSorin Basca <tt>instanceof</tt> operator can be directly mapped to the 265*0c56280aSSorin Basca equally named instruction. 266*0c56280aSSorin Basca </p> 267*0c56280aSSorin Basca 268*0c56280aSSorin Basca <p> 269*0c56280aSSorin Basca Most instructions have a fixed length, but there are also some 270*0c56280aSSorin Basca variable-length instructions: In particular, the 271*0c56280aSSorin Basca <tt>lookupswitch</tt> and <tt>tableswitch</tt> instructions, which 272*0c56280aSSorin Basca are used to implement <tt>switch()</tt> statements. Since the 273*0c56280aSSorin Basca number of <tt>case</tt> clauses may vary, these instructions 274*0c56280aSSorin Basca contain a variable number of statements. 275*0c56280aSSorin Basca </p> 276*0c56280aSSorin Basca 277*0c56280aSSorin Basca <p> 278*0c56280aSSorin Basca We will not list all byte code instructions here, since these are 279*0c56280aSSorin Basca explained in detail in the <a 280*0c56280aSSorin Basca href="http://docs.oracle.com/javase/specs/">JVM 281*0c56280aSSorin Basca specification</a>. The opcode names are mostly self-explaining, 282*0c56280aSSorin Basca so understanding the following code examples should be fairly 283*0c56280aSSorin Basca intuitive. 284*0c56280aSSorin Basca </p> 285*0c56280aSSorin Basca 286*0c56280aSSorin Basca </subsection> 287*0c56280aSSorin Basca 288*0c56280aSSorin Basca <subsection name="Method code"> 289*0c56280aSSorin Basca <p> 290*0c56280aSSorin Basca Non-abstract (and non-native) methods contain an attribute 291*0c56280aSSorin Basca "<tt>Code</tt>" that holds the following data: The maximum size of 292*0c56280aSSorin Basca the method's stack frame, the number of local variables and an 293*0c56280aSSorin Basca array of byte code instructions. Optionally, it may also contain 294*0c56280aSSorin Basca information about the names of local variables and source file 295*0c56280aSSorin Basca line numbers that can be used by a debugger. 296*0c56280aSSorin Basca </p> 297*0c56280aSSorin Basca 298*0c56280aSSorin Basca <p> 299*0c56280aSSorin Basca Whenever an exception is raised during execution, the JVM performs 300*0c56280aSSorin Basca exception handling by looking into a table of exception 301*0c56280aSSorin Basca handlers. The table marks handlers, i.e., code chunks, to be 302*0c56280aSSorin Basca responsible for exceptions of certain types that are raised within 303*0c56280aSSorin Basca a given area of the byte code. When there is no appropriate 304*0c56280aSSorin Basca handler the exception is propagated back to the caller of the 305*0c56280aSSorin Basca method. The handler information is itself stored in an attribute 306*0c56280aSSorin Basca contained within the <tt>Code</tt> attribute. 307*0c56280aSSorin Basca </p> 308*0c56280aSSorin Basca 309*0c56280aSSorin Basca </subsection> 310*0c56280aSSorin Basca 311*0c56280aSSorin Basca <subsection name="Byte code offsets"> 312*0c56280aSSorin Basca <p> 313*0c56280aSSorin Basca Targets of branch instructions like <tt>goto</tt> are encoded as 314*0c56280aSSorin Basca relative offsets in the array of byte codes. Exception handlers 315*0c56280aSSorin Basca and local variables refer to absolute addresses within the byte 316*0c56280aSSorin Basca code. The former contains references to the start and the end of 317*0c56280aSSorin Basca the <tt>try</tt> block, and to the instruction handler code. The 318*0c56280aSSorin Basca latter marks the range in which a local variable is valid, i.e., 319*0c56280aSSorin Basca its scope. This makes it difficult to insert or delete code areas 320*0c56280aSSorin Basca on this level of abstraction, since one has to recompute the 321*0c56280aSSorin Basca offsets every time and update the referring objects. We will see 322*0c56280aSSorin Basca in <a href="bcel-api.html#ClassGen">section 3.3</a> how <font 323*0c56280aSSorin Basca face="helvetica,arial">BCEL</font> remedies this restriction. 324*0c56280aSSorin Basca </p> 325*0c56280aSSorin Basca 326*0c56280aSSorin Basca </subsection> 327*0c56280aSSorin Basca 328*0c56280aSSorin Basca <subsection name="Type information"> 329*0c56280aSSorin Basca <p> 330*0c56280aSSorin Basca Java is a type-safe language and the information about the types 331*0c56280aSSorin Basca of fields, local variables, and methods is stored in so called 332*0c56280aSSorin Basca <em>signatures</em>. These are strings stored in the constant pool 333*0c56280aSSorin Basca and encoded in a special format. For example the argument and 334*0c56280aSSorin Basca return types of the <tt>main</tt> method 335*0c56280aSSorin Basca </p> 336*0c56280aSSorin Basca 337*0c56280aSSorin Basca <p align="center"> 338*0c56280aSSorin Basca <source>public static void main(String[] argv)</source> 339*0c56280aSSorin Basca </p> 340*0c56280aSSorin Basca 341*0c56280aSSorin Basca <p> 342*0c56280aSSorin Basca are represented by the signature 343*0c56280aSSorin Basca </p> 344*0c56280aSSorin Basca 345*0c56280aSSorin Basca <p align="center"> 346*0c56280aSSorin Basca <source>([java/lang/String;)V</source> 347*0c56280aSSorin Basca </p> 348*0c56280aSSorin Basca 349*0c56280aSSorin Basca <p> 350*0c56280aSSorin Basca Classes are internally represented by strings like 351*0c56280aSSorin Basca <tt>"java/lang/String"</tt>, basic types like <tt>float</tt> by an 352*0c56280aSSorin Basca integer number. Within signatures they are represented by single 353*0c56280aSSorin Basca characters, e.g., <tt>I</tt>, for integer. Arrays are denoted with 354*0c56280aSSorin Basca a <tt>[</tt> at the start of the signature. 355*0c56280aSSorin Basca </p> 356*0c56280aSSorin Basca 357*0c56280aSSorin Basca </subsection> 358*0c56280aSSorin Basca 359*0c56280aSSorin Basca <subsection name="Code example"> 360*0c56280aSSorin Basca <p> 361*0c56280aSSorin Basca The following example program prompts for a number and prints the 362*0c56280aSSorin Basca factorial of it. The <tt>readLine()</tt> method reading from the 363*0c56280aSSorin Basca standard input may raise an <tt>IOException</tt> and if a 364*0c56280aSSorin Basca misspelled number is passed to <tt>parseInt()</tt> it throws a 365*0c56280aSSorin Basca <tt>NumberFormatException</tt>. Thus, the critical area of code 366*0c56280aSSorin Basca must be encapsulated in a <tt>try-catch</tt> block. 367*0c56280aSSorin Basca </p> 368*0c56280aSSorin Basca 369*0c56280aSSorin Basca <source> 370*0c56280aSSorin Bascaimport java.io.*; 371*0c56280aSSorin Basca 372*0c56280aSSorin Bascapublic class Factorial { 373*0c56280aSSorin Basca private static BufferedReader in = new BufferedReader(new InputStreamReader(System.in)); 374*0c56280aSSorin Basca 375*0c56280aSSorin Basca public static int fac(int n) { 376*0c56280aSSorin Basca return (n == 0) ? 1 : n * fac(n - 1); 377*0c56280aSSorin Basca } 378*0c56280aSSorin Basca 379*0c56280aSSorin Basca public static int readInt() { 380*0c56280aSSorin Basca int n = 4711; 381*0c56280aSSorin Basca try { 382*0c56280aSSorin Basca System.out.print("Please enter a number> "); 383*0c56280aSSorin Basca n = Integer.parseInt(in.readLine()); 384*0c56280aSSorin Basca } catch (IOException e1) { 385*0c56280aSSorin Basca System.err.println(e1); 386*0c56280aSSorin Basca } catch (NumberFormatException e2) { 387*0c56280aSSorin Basca System.err.println(e2); 388*0c56280aSSorin Basca } 389*0c56280aSSorin Basca return n; 390*0c56280aSSorin Basca } 391*0c56280aSSorin Basca 392*0c56280aSSorin Basca public static void main(String[] argv) { 393*0c56280aSSorin Basca int n = readInt(); 394*0c56280aSSorin Basca System.out.println("Factorial of " + n + " is " + fac(n)); 395*0c56280aSSorin Basca } 396*0c56280aSSorin Basca} 397*0c56280aSSorin Basca </source> 398*0c56280aSSorin Basca 399*0c56280aSSorin Basca <p> 400*0c56280aSSorin Basca This code example typically compiles to the following chunks of 401*0c56280aSSorin Basca byte code: 402*0c56280aSSorin Basca </p> 403*0c56280aSSorin Basca 404*0c56280aSSorin Basca <source> 405*0c56280aSSorin Basca 0: iload_0 406*0c56280aSSorin Basca 1: ifne #8 407*0c56280aSSorin Basca 4: iconst_1 408*0c56280aSSorin Basca 5: goto #16 409*0c56280aSSorin Basca 8: iload_0 410*0c56280aSSorin Basca 9: iload_0 411*0c56280aSSorin Basca 10: iconst_1 412*0c56280aSSorin Basca 11: isub 413*0c56280aSSorin Basca 12: invokestatic Factorial.fac (I)I (12) 414*0c56280aSSorin Basca 15: imul 415*0c56280aSSorin Basca 16: ireturn 416*0c56280aSSorin Basca 417*0c56280aSSorin Basca LocalVariable(start_pc = 0, length = 16, index = 0:int n) 418*0c56280aSSorin Basca </source> 419*0c56280aSSorin Basca 420*0c56280aSSorin Basca <p><b>fac():</b> 421*0c56280aSSorin Basca The method <tt>fac</tt> has only one local variable, the argument 422*0c56280aSSorin Basca <tt>n</tt>, stored at index 0. This variable's scope ranges from 423*0c56280aSSorin Basca the start of the byte code sequence to the very end. If the value 424*0c56280aSSorin Basca of <tt>n</tt> (the value fetched with <tt>iload_0</tt>) is not 425*0c56280aSSorin Basca equal to 0, the <tt>ifne</tt> instruction branches to the byte 426*0c56280aSSorin Basca code at offset 8, otherwise a 1 is pushed onto the operand stack 427*0c56280aSSorin Basca and the control flow branches to the final return. For ease of 428*0c56280aSSorin Basca reading, the offsets of the branch instructions, which are 429*0c56280aSSorin Basca actually relative, are displayed as absolute addresses in these 430*0c56280aSSorin Basca examples. 431*0c56280aSSorin Basca </p> 432*0c56280aSSorin Basca 433*0c56280aSSorin Basca <p> 434*0c56280aSSorin Basca If recursion has to continue, the arguments for the multiplication 435*0c56280aSSorin Basca (<tt>n</tt> and <tt>fac(n - 1)</tt>) are evaluated and the results 436*0c56280aSSorin Basca pushed onto the operand stack. After the multiplication operation 437*0c56280aSSorin Basca has been performed the function returns the computed value from 438*0c56280aSSorin Basca the top of the stack. 439*0c56280aSSorin Basca </p> 440*0c56280aSSorin Basca 441*0c56280aSSorin Basca <source> 442*0c56280aSSorin Basca 0: sipush 4711 443*0c56280aSSorin Basca 3: istore_0 444*0c56280aSSorin Basca 4: getstatic java.lang.System.out Ljava/io/PrintStream; 445*0c56280aSSorin Basca 7: ldc "Please enter a number> " 446*0c56280aSSorin Basca 9: invokevirtual java.io.PrintStream.print (Ljava/lang/String;)V 447*0c56280aSSorin Basca 12: getstatic Factorial.in Ljava/io/BufferedReader; 448*0c56280aSSorin Basca 15: invokevirtual java.io.BufferedReader.readLine ()Ljava/lang/String; 449*0c56280aSSorin Basca 18: invokestatic java.lang.Integer.parseInt (Ljava/lang/String;)I 450*0c56280aSSorin Basca 21: istore_0 451*0c56280aSSorin Basca 22: goto #44 452*0c56280aSSorin Basca 25: astore_1 453*0c56280aSSorin Basca 26: getstatic java.lang.System.err Ljava/io/PrintStream; 454*0c56280aSSorin Basca 29: aload_1 455*0c56280aSSorin Basca 30: invokevirtual java.io.PrintStream.println (Ljava/lang/Object;)V 456*0c56280aSSorin Basca 33: goto #44 457*0c56280aSSorin Basca 36: astore_1 458*0c56280aSSorin Basca 37: getstatic java.lang.System.err Ljava/io/PrintStream; 459*0c56280aSSorin Basca 40: aload_1 460*0c56280aSSorin Basca 41: invokevirtual java.io.PrintStream.println (Ljava/lang/Object;)V 461*0c56280aSSorin Basca 44: iload_0 462*0c56280aSSorin Basca 45: ireturn 463*0c56280aSSorin Basca 464*0c56280aSSorin Basca Exception handler(s) = 465*0c56280aSSorin Basca From To Handler Type 466*0c56280aSSorin Basca 4 22 25 java.io.IOException(6) 467*0c56280aSSorin Basca 4 22 36 NumberFormatException(10) 468*0c56280aSSorin Basca </source> 469*0c56280aSSorin Basca 470*0c56280aSSorin Basca <p><b>readInt():</b> First the local variable <tt>n</tt> (at index 0) 471*0c56280aSSorin Basca is initialized to the value 4711. The next instruction, 472*0c56280aSSorin Basca <tt>getstatic</tt>, loads the references held by the static 473*0c56280aSSorin Basca <tt>System.out</tt> field onto the stack. Then a string is loaded 474*0c56280aSSorin Basca and printed, a number read from the standard input and assigned to 475*0c56280aSSorin Basca <tt>n</tt>. 476*0c56280aSSorin Basca </p> 477*0c56280aSSorin Basca 478*0c56280aSSorin Basca <p> 479*0c56280aSSorin Basca If one of the called methods (<tt>readLine()</tt> and 480*0c56280aSSorin Basca <tt>parseInt()</tt>) throws an exception, the Java Virtual Machine 481*0c56280aSSorin Basca calls one of the declared exception handlers, depending on the 482*0c56280aSSorin Basca type of the exception. The <tt>try</tt>-clause itself does not 483*0c56280aSSorin Basca produce any code, it merely defines the range in which the 484*0c56280aSSorin Basca subsequent handlers are active. In the example, the specified 485*0c56280aSSorin Basca source code area maps to a byte code area ranging from offset 4 486*0c56280aSSorin Basca (inclusive) to 22 (exclusive). If no exception has occurred 487*0c56280aSSorin Basca ("normal" execution flow) the <tt>goto</tt> instructions branch 488*0c56280aSSorin Basca behind the handler code. There the value of <tt>n</tt> is loaded 489*0c56280aSSorin Basca and returned. 490*0c56280aSSorin Basca </p> 491*0c56280aSSorin Basca 492*0c56280aSSorin Basca <p> 493*0c56280aSSorin Basca The handler for <tt>java.io.IOException</tt> starts at 494*0c56280aSSorin Basca offset 25. It simply prints the error and branches back to the 495*0c56280aSSorin Basca normal execution flow, i.e., as if no exception had occurred. 496*0c56280aSSorin Basca </p> 497*0c56280aSSorin Basca 498*0c56280aSSorin Basca </subsection> 499*0c56280aSSorin Basca </section> 500*0c56280aSSorin Basca </body> 501*0c56280aSSorin Basca 502*0c56280aSSorin Basca</document>
