Java Virtual Machine

Java Virtual Machine Instructors: Fu-Chiung Cheng (鄭福炯) Associate Professor Computer Science & Engineering Tatung University

Java Virtual Machine • JVM may mean • the abstract specification • The Java Virtual Machine Specification, by Tim Lindholm and Frank Yellin. • a concrete implementation or • all software or a combination of hardware and software. • By many vendors for many platforms • a runtime instance • A runtime instance hosts a single running Java application.

Java Virtual Machine • Each Java application runs inside a runtime instance of some concrete implementation of the abstract specification of the Java virtual machine. • JVM: "specification," "implementation," or "instance" • This lecture focuses on Java Runtime instance.

Java Program class SumI { public static void main (String[] args) { int count=10; int sum =0; for (int index=1;index<count;index++) sum=sum+index; } // method main } // class SumI

Java ByteCode Method void main(java.lang.String[]) 0 bipush 10 // byte push 10 to stack (0x10) 2 istore_1 // load 10 (top of stack) to count 3 iconst_0 // push 0 to stack 4 istore_2 // load 0 (top of stack to sum 5 iconst_1 // push 1 to stack 6 istore_3 // load 1 (top of stack) to index 7 goto 17 // go to 17

Java ByteCode 10 iload_2 // load sum to stack 11 iload_3 // load index to stack 12 iadd // add 13 istore_2 // store “top of stack” to sum 14 iinc 3 1 // index ++ 17 iload_3 // load index to stack 18 iload_1 // load count to stack 19 if_icmplt 10 // if index < count goto 10 22 return

Java Virtual Machine • A runtime instance of the JVM has a clear mission in life: to run one Java application. • When a Java application starts, a runtime instance is born. • When the application completes, the instance dies. • If you start three Java applications at the same time, on the same computer, using the same concrete implementation, you'll get three Java virtual machine instances. • Each Java application runs inside its own JVM.

Internal Architecture of JVM Class loader subsystem class files method area heap Java stacks pc registers native method stacks Runtime data area Native Method Libraries Native Method Interface Execution engine

Internal Architecture of JVM • Class loader subsystem: a mechanism for loading • classes or interfaces. • Execution engine: a mechanism for executing the • instructions contained in the methods of loaded • classes. • Runtime data area: a memory to store • bytecodes (method area), objects (heap), • parameters, return values, local variables, (stack) • results of intermediate computations (stack). • JVM spec. is abstract ==> designers are free to • implement JVM by their own structure.

Internal Architecture of JVM • Some runtime data areas are shared among all of an application's threads and others are unique to individual threads. • Each instance of the Java virtual machine has one method area and one heap. • Method area and heap are shared by all threads running inside the virtual machine.

Internal Architecture of JVM • When the virtual machine loads a class file, it parses information about a type from the binary data contained in the class file. • JVM places this type information into the method area. • As the program runs, the virtual machine places all objects the program instantiates onto the heap.

Runtime Data Area Shared among threads object class data object class data object class data object object object class data class data object object class data object Method area heap

Threads • Java supports multi-thread applications. • Multi-thread: A process can be broken into several • separate threads of control which execute at the • same time. • A thread is one sequential flow of execution that • occurs at the same time another thread is executing • the statement of the same program • Each thread has its own PC register (program • counter) and Java Stack.

Threads • PC register: pointer to next instruction to be executed. • Java Stack: parameters, return values, local • variables, results of intermediate computations. • The Java stack is composed of stack frames. • A stack frame contains the state of one Java • method invocation. • When a thread invokes a method, the JVM pushes • a new frame onto that thread's Java stack. • When the method completes, JVM pops and • discards the frame for that method.

Thread’s Runtime Data Area thread 2 thread 3 thread 1 thread 1 stack frame stack frame stack frame thread 3 thread 2 stack frame stack frame stack frame thread 3 stack frame stack frame stack frame native method stacks pc registers java stacks

Thread’s Runtime Data Area • Java Stacks: state of Java method invocation. • Native method stacks: state of native method • invocation. • In the example: • Previous Figure shows a snapshot of a JVM in • which three threads are executing. • A. Thread 1 and 2 are executing Java methods: • PC registers of Thread 1 and 2 are pointed to • the next instruction to be executed • B. Thread 3 is executing a native method: • PC register of Thread 3 is undefined.

Class Loader Subsystem(chap 5) • Loading: finding and importing the binary data for a • type (class or interface). • Linking: performing verification, preparation, and • (optionally) resolution • Verification: ensuring the correctness of the • imported type • Preparation: allocating memory for class variables • and initializing the memory to default values • Resolution: transforming symbolic references • from the type into direct references. • 3.Initialization: invoking Java code that initializes class • variables to their proper starting values.

Class Loader • VM contains two kinds of class loaders: • a bootstrap class loader and • user-defined class loaders. • The bootstrap class loader is a part of the VM implementation, and user-defined class loaders are part of the running Java application. • Classes loaded by different class loaders are placed into separate name spaces inside the Java virtual machine.

Bootstrap class loader • Every JVM implementation has a bootstrap class loader, which knows how to load trusted classes, including the classes of the Java API. • Use java –X to see non-standard JVM options (JDK1.2 and later) • java –bootclasspath • java –bootclasspath/a (append to the end of bootclasspath) • java –bootclasspath/p (prepend in front of )

User-defined class loaders • User may dynamically create classes and load into JVM. • Four of the methods declared in class java.lang.ClassLoader (part of Java APIs): • protected final Class defineClass(String name, byte data[],int offset, int length); • protected final Class defineClass(String name, byte data[], int offset, int length, ProtectionDomain protectionDomain); • name: fully qualified class name • data[]: .class file • protectionDomain: different name space

User-defined class loaders • protected final Class findSystemClass(String name); • name: representing a fully qualified name • throw ClassNotFoundException if JVM can not locate the type. • protected final void resolveClass(Class c); • c: class instance created by defineClass • defineClass: load the binary file for the type and import the type into the method area, • resolveClass: linking (performing verification, preparation, and resolution) and initialization

User-defined class loaders • defineClass converts an array of bytes into an instance of class Class. • Instances of this newly defined class can be created using the newInstance method in class Class. • findSystemClass

Class Loader Subsystem(chap 07) • Class loader subsystem: finding and loading types • A. Loading: find and import the binary data for a type. • B. Linking: • 1. Verification: • A. verify .class file is well-formed with a proper • symbol table. • B. verify that bytecode obeys the semantic • requirements of the Java Virtual Machine. • C. Example: VM checks • 1. every instruction has a valid operation code • 2. Every branch instruction branches to the • start (not middle) of some other instruction.

Class Loader Subsystem B. Linking: 2. Preparation: A. allocating memory for class variables and initializing the memory to default values. B. allocating data structures that are used internally by the virtual machine: 1. method tables. 2. data structure that allows any method to be invoked on instances of a class without requiring a search of superclasses at invocation time.

Class Loader Subsystem B. Linking: 3. Resolution: A. transforming symbolic references (e.g. class.field) into direct references. B. symbolic reference is replaced with a direct reference that can be more efficiently processed if the reference is used repeatedly. (Quick instructions) C. Implementation choice: static linkage vs. laziest resolution

Class Loader Subsystem C. Initialization: invoke java code that initializes class variables to their proper staring values. A. execution of any class variable initializers B. Before a class can be initialized, its direct superclass must be initialized, as well as the direct superclass of its direct superclass. C. Initialization may cause loading, linking, and initialization errors D. Because Java is multithreaded, initialization of a class or interface requires careful synchronization.

Class Loader Subsystem • Class loaders of JVM (for Java 1.0 and 1.1) • A. Primordial class loader: load trusted class. • It looks in the each directory, in the order the • directories appear in the CLASSPATH, until a file • with appropriate name (filename.class) is found. • B. Class loader objects: • 1. Class loader objects(java.lang.ClassLoader) are • part of the Java APIs. • 2. Three methods in ClassLoader (defineClass • findSystemClass, resolveClass) are the gateway • into JVM.

Method Area • Inside a JVM instance, information about loaded types is stored in a logical area of memory called the method area. • Class loader reads in the class file (a linear stream of bytes) and pass it to VM. • VM extracts information about the type from the binary data and stores the information in method area. • Class (static) variables are stored in method area. • All threads share the same method area, so access to the method area's data structures must be designed to be thread-safe.

Type Information stored in Method Area • Fully qualified name of the type (ex. java.lang.Object) • Fully qualified name of its superclass • class or interface • type’s modifier (public, abstract, final) • List of interface • Constant pool: • literals, symbolic links to types, fields, methods. • Field information: field name, type, modifiers • Method information: name, return type, parameters, • modifiers, method’s bytecodes, size of operand stack • size of local variables, exception table

Type Information stored in Method Area • Static variables: class variables are shared by all • instances of a class. (must allocate space in method • area before anyone uses it.) • A reference to class ClassLoader for dynamic linking • A reference to class Class

Constant pool (CP) • For each type it loads, a JVM must store a CP. • A CP is an ordered set of constants used by the type, including literals (string, integer, and floating point constants) and symbolic references to types, fields, and methods. • Entries in the CP are referenced by index, much like the elements of an array. • Because CP holds symbolic references to all types, fields, and methods used by a type, CP plays a central role in the dynamic linking of Java programs.

Field Information • For each field declared in the type, the following information must be stored in the method area. • The field's name • The field's type • The field's modifiers (some subset of public, private, protected, static, final, volatile, transient) • In addition to the information for each field, the order in which the fields are declared by the class or interface must also be recorded.

Method Information • For each method declared in the type, the following info must be stored in the method area. • The method's name and return type (or void) • The number and types (in order) of the method's parameters • The method's modifiers (some subset of public, private, protected, static, final, synchronized, native, abstract) • As with fields, the order in which the methods are declared by the class or interface must be recorded as well as the data.

Method Information • In addition to the items listed previously, the following information must also be stored with each method that is not abstract or native: • The method's bytecodes • The sizes of the operand stack and local variables sections of the method's stack frame • An exception table (more detail in Chapter 17, "Exceptions")

Class Variables • Class variables are shared among all instances of a class and can be accessed even in the absence of any instance. • These variables are associated with the class--not with instances of the class--so they are logically part of the class data in the method area. • Before a Java virtual machine uses a class, it must allocate memory from the method area for each non-final class variable declared in the class.

Class Variables • Constants (class variables declared final) are not treated in the same way as non-final class variables. • Every type that uses a final class variable gets a copy of the constant value in its own constant pool. • As part of the constant pool, final class variables are stored in the method area--just like non-final class variables.

A Reference to Class ClassLoader • For each type it loads, a JVM must keep track of whether or not the type was loaded via the bootstrap class loader or a user-defined class loader. • For those types loaded via a user-defined class loader, the VM must store a reference to the user-defined class loader that loaded the type. • This information is stored as part of the type's data in the method area.

A Reference to Class ClassLoader • The VM uses this information during dynamic linking. • When one type refers to another type, the VM requests the referenced type from the same class loader that loaded the referencing type. • To be able to properly perform dynamic linking and maintain multiple name spaces, the VM needs to know what class loader loaded each type in its method area.

Method Table • The type information stored in method area must be organized to be quickly accessible. • A method table is an array of direct references to all the instance methods that may be invoked on a class instance, including instance methods inherited from superclasses. • A method table allows a virtual machine to quickly locate an instance method invoked on an object. • Method table is not helpful for abstract classes or interfaces. (not instantiated)

An Example of Method Area Use // On CD-ROM in file jvm/ex2/Lava.java class Lava { private int speed = 5; //5km per hour void flow() { } } // On CD-ROM in file jvm/ex2/Volcano.java class Volcano { public static void main(String[] args) { Lava lava = new Lava(); lava.flow(); } }

An Example of Method Area Use • JVM executes the first instruction in the bytecodes for the main() method of the Volcano application. • Given the name Volcano, the VM finds and reads in file Volcano.class. • It extracts the definition of class Volcano from the binary data in the imported class file and places the information into the method area. • The VM then invokes the main() method, by interpreting the bytecodes stored in the method area. • As the virtual machine executes main(), it maintains a pointer to the constant pool (a data structure in the method area) for the current class (class Volcano).

An Example of Method Area Use • Note that this JVM has already begun to execute the bytecodes for main() in class Volcano even though it hasn't yet loaded class Lava. • JVM loads classes only as it needs them. • JVM (dynamically) loads Lava class. • main()'s first instruction tells the JVM to allocate enough memory for the class listed in constant pool entry one. • The VM uses its pointer into Volcano's constant pool to look up entry one and finds a symbolic reference to class Lava. • It checks the method area to see if Lava has already been loaded.

An Example of Method Area Use • Cont. • When the virtual machine discovers that it has not yet loaded a class named "Lava," it proceeds to find and read in file Lava.class. • It extracts the definition of class Lava from the imported binary data and places the information into the method area. • The Java virtual machine then replaces the symbolic reference in Volcano's constant pool entry one, which is just the string "Lava", with a pointer to the class data for Lava.

An Example of Method Area Use • Cont. • If the virtual machine ever has to use Volcano's constant pool entry one again, it won't have to go through the relatively slow process of searching through the method area for class Lava given only a symbolic reference, the string "Lava". • It can just use the pointer to more quickly access the class data for Lava. • This process of replacing symbolic references with direct references is called constant pool resolution.

An Example of Method Area Use • Cont. • The symbolic reference is resolved into a direct reference by searching through the method area until the referenced entity is found, loading new classes if necessary. • Finally, the VM is ready to actually allocate memory for a new Lava object. • Once again, the VM consults the information stored in the method area. • It uses the pointer to the Lava data to find out how much heap space is required by a Lava object.

An Example of Method Area Use • A JVM can always determine the amount of memory required to represent an object by looking into the class data stored in the method area. • The actual amount of heap space required by a particular object, however, is implementation-dependent. • The internal representation of objects inside a JVM is another decision of implementation designers.

An Example of Method Area Use • Cont. • Once the JVM has determined the amount of heap space required by a Lava object, it allocates that space on the heap and initializes the instance variable speed to zero, its default initial value. • If class Lava's superclass, Object, has any instance variables, those are also initialized to default initial values. • The first instruction of main() completes by pushing a reference to the new Lava object onto the stack.

An Example of Method Area Use • Cont. • A later instruction will use the reference to invoke Java code that initializes the speed variable to its proper initial value, five. • Another instruction will use the reference to invoke the flow() method on the referenced Lava object.

Trade-off of design the data structure of Method Area • Designers must attempt to devise data structures that will facilitate speedy execution of the Java application as well as compactness. • If designing an implementation that will operate under low memory constraints, designers may decide to trade off some execution speed in favor of compactness. • If designing an implementation that will run on a virtual memory system, designers may decide to store redundant information in the method area to facilitate execution speed.

Heap • New objects are allocated by JVM in heap. • A heap exists in every JVM instance. Thus, two • different applications can not trample on each • other’s heap. • Heap are shared by all threads. Thus, • synchronization between threads is needed. • Garbage Collector is responsible for freeing • Objects. • Note objects (in heap) and class (in method area) • may be freed by Garbage Collection.

Java Virtual Machine