JVM. What This Topic is About. Course Overview. Recap: Interpretive Compilers. Abstract Machines. Abstract Machines. Class Files and Class File Format

Transcription

1 Course Overview What This Topic is About PART I: overview material 1 Introduction 2 Language processors (tombstone diagrams, bootstrapping) 3 Architecture of a compiler PART II: inside a compiler 4 Syntax analysis 5 Contextual analysis 6 Runtime organization 7 Code generation PART III: conclusion 8 Interpretation 9 Review Supplementary material: s runtime organization and the Virtual Machine 1 We look at the JVM as an example of a real-world runtime system for a modern object-oriented programming language. JVM is probably the most common and widely used VM in the world, so you ll get a better idea what a real VM looks like. JVM is an abstract machine. What is the JVM architecture? What is the structure of.class files? How are JVM instructions executed? What is the role of the constant pool in dynamic linking? Also visit this site for more complete information about the JVM: 2 Recap: Interpretive Compilers Abstract Machines Why? A tradeoff between fast(er) compilation and a reasonable runtime performance. How? Use an intermediate language more high-level than machine code => easier to compile to more low-level than source language => easy to implement as an interpreter Example: A Development Kit for machine M >JVM M JVM M Abstract machine implements an intermediate language in between the high-level language (e.g. ) and the low-level hardware (e.g. Pentium) High level Low level Pentium JVM (.class files) Pentium Implemented in : Machine independent compiler JVM interpreter or JVM JIT compiler 3 4 Abstract Machines Class Files and Class File Format An abstract machine is intended specifically as a runtime system for a particular (kind of) programming language. JVM is a virtual machine for programs. It directly supports object-oriented concepts such as classes, objects, methods, method invocation etc. Easy to compile to JVM => 1. easy to implement compiler 2. fast compilation Another advantage: portability External representation (platform independent).class files load JVM Internal representation (implementation dependent) classes objects arrays primitive types methods strings The JVM is an abstract machine in the truest sense of the word. The JVM specification does not give implementation details (can be dependent on target OS/platform, performance requirements, etc.) The JVM specification defines a machine independent class file format that all JVM implementations must support

2 Data Types JVM (and ) distinguishes between two kinds of types: Primitive types: boolean: boolean numeric integral: byte, short, int, long, char numeric floating point:float, double internal, for exception handling: returnaddress JVM: Runtime Data Areas Besides OO concepts, JVM also supports multi-threading. Threads are directly supported by the JVM. => Two kinds of runtime data areas: 1. shared between all threads 2. private to a single thread Shared Thread 1 Thread 2 Reference types: class types array types interface types Note: Primitive types are represented directly, reference types are represented indirectly (as pointers to array or class instances). 7 Garbage Collected Heap Method area pc Native Method pc Native Method 8 s Frames JVM is a stack based machine, much like TAM. JVM instructions implicitly take arguments from the stack top put their result on the top of the stack The stack is used to pass arguments to methods return a result from a method store intermediate results while evaluating expressions store local variables This works similarly to (but not exactly the same as) what we previously discussed about stack-based storage allocation and routines. The stack consists of frames. The JVM specification does not say exactly how the stack and frames should be implemented. The JVM specification specifies that a stack frame has areas for: args + local vars operand stack Pointer to runtime constant pool A new call frame is created by executing some JVM instruction for invoking a method (e.g. invokevirtual, invokenonvirtual,...) The operand stack is initially empty, but grows and shrinks during execution pointer to constant pool args + local vars operand stack Frames The role/purpose of each of the areas in a stack frame: Used implicitly when executing JVM instructions that contain entries into the constant pool (more about this later). Space where the arguments and local variables of a method are stored. This includes a space for the receiver (this) at position/offset 0. for storing intermediate results during the execution of the method. Initially it is empty. The maximum depth is known at compile time. 11 Frames An implementation using registers such as SB, ST, and LB and a dynamic link is one possible implementation. SB to previous frame on the stack LB ST dynamic link args + local vars operand stack to runtime constant pool JVM instructions store and load (for accessing args and locals) use addresses which are numbers from 0 to #args + #locals

3 JVM Interpreter Instruction-set: typed instructions! The core of a JVM interpreter is basically this: do { byte opcode = fetch an opcode; switch (opcode) { case opcode1 : fetch operands for opcode1; execute action for opcode1; break; case opcode2 : fetch operands for opcode2; execute action for opcode2; break; case... while (more to do) JVM instructions are explicitly typed: different opcodes for instructions for integers, floats, arrays, reference types, etc. This is reflected by a naming convention in the first letter of the opcode mnemonics: Example: different types of load instructions iload lload fload dload aload integer load long load float load double load reference-type load Instruction set: kinds of operands Instruction-set: accessing arguments and locals JVM instructions have three kinds of operands: - from the top of the operand stack - from the bytes following the opcode - part of the opcode itself Each instruction may have different forms supporting different kinds of operands. Example: different forms of iload Assembly code iload_0 iload_1 iload_2 iload_3 iload n Binary instruction code layout n wide iload n n 15 0: 1: 2: 3: arguments and locals area inside a stack frame Instruction examples: iload_1 iload_3 aload 5 aload_0 istore_1 astore_1 fstore_3 args: indexes 0.. #args - 1 locals: indexes #args.. #args + #locals - 1 A load instruction takes something from the args/locals area and pushes it onto the top of the operand stack. A store instruction pops something from the top of the operand stack and places it in the args/locals area. 16 Instruction-set: non-local memory access Instruction-set: operations on numbers In the JVM, the contents of different kinds of memory can be accessed by different kinds of instructions. accessing locals and arguments: load and storeinstructions accessing fields in objects:getfield, putfield accessing static fields:getstatic, putstatic Note: Static fields are a lot like global variables. They are allocated in the method area where also code for methods and representations for classes (including method tables) are stored. Arithmetic add: iadd, ladd, fadd, dadd subtract: isub, lsub, fsub, dsub multiply: imul, lmul, fmul, dmul etc. Conversion i2l, i2f, i2d, l2f, l2d, f2d, f2i, d2i, Note: getfield and putfieldaccess memory in the heap. Note: JVM doesn t have anything similar to registers L1, L2, etc

4 Instruction-set Operand stack manipulation pop, pop2, dup, dup2, swap, Control transfer Unconditional:goto, jsr, ret, Conditional: ifeq, iflt, ifgt, if_icmpeq, Instruction-set Method invocation: invokevirtual: usual instruction for calling a method on an object. invokeinterface: same as invokevirtual, but used when the called method is declared in an interface (requires a different kind of method lookup) invokespecial: for calling things such as constructors, which are not dynamically dispatched (this instruction is also known as invokenonvirtual). invokestatic: for calling methods that have the static modifier (these methods are sent to a class, not to an object). Returning from methods: return, ireturn, lreturn, areturn, freturn, Instruction-set: Heap Memory Allocation Create new class instance (object): new Create new array: newarray: for creating arrays of primitive types. anewarray, multianewarray: for arrays of reference types. Many JVM instructions have operands which are indexes pointing to an entry in the so-called constant pool. The constant pool contains all kinds of entries that represent symbolic references for linking. This is the way that instructions refer to things such as classes, interfaces, fields, methods, and constants such as string literals and numbers. These are the kinds of constant pool entries that exist: Class_info Fieldref_info Methodref_info InterfaceMethodref_info String Integer Float Long Double Name_and_Type_info Utf8_info (Unicode characters) Example: We examine the getfield instruction in detail. Format: CONSTANT_Fieldref_info { u1 tag; u2 class_index; u2 name_and_type_index; 180 indexbyte1 indexbyte2 CONSTANT_Name_and_Type_info { u1 tag; u2 name_index; u2 descriptor_index; Class_info { u1 tag; u2 name_index; name of field field descriptor fully qualified class name 23 That previous picture is rather complicated, let s simplify it a little: Format: Class fully qualified class name 180 indexbyte1 indexbyte2 name of field Fieldref Name_and_Type field descriptor 24 4

5 The constant entries format is part of the class file format. Luckily, we have a assembler that allows us to write a kind of textual assembly code and that is then transformed into a binary.class file. Fully qualified class names and descriptors in constant pool UTF8 entries. 1. Fully qualified class name: a package + class name string. Note this uses / instead of. to separate each level along the path. This assembler takes care of creating the constant pool entries for us. When an instruction operand expects a constant pool entry the assembler allows you to enter the entry in place in an easy syntax. Example: getfield mypackage/queue i I 2. Descriptor: a string that defines a type for a method or field. boolean integer Object String[] int foo(int,object) descriptor Z I Ljava/lang/Object; [Ljava/lang/String; (ILjava/lang/Object;)I Linking Loading and Linking in JVM In general, linking is the process of resolving symbolic references in binary files. In JVM, loading and linking of class files happens at runtime, while the program is running! Most programming language implementations have what we call separate compilation. Modules or files can be compiled separately and transformed into some binary format. But since these separately compiled files may have connections to other files, they have to be linked. Classes are loaded as needed. The constant pool contains symbolic references that need to be resolved before a JVM instruction that uses them can be executed (this is the equivalent of linking). => The binary file is not yet executable, because it has some kind of symbolic links in it that point to things (classes, methods, functions, variables, etc.) in other files/modules. Linking is the process of resolving these symbolic links and replacing them by real addresses so that the code can be executed. 27 In JVM a constant pool entry is resolved the first time it is used by a JVM instruction. Example: When a getfieldis executed for the first time, the constant pool entry index in the instruction can be replaced by the offset of the field. 28 class Factorial { Closing Example As a closing example on the JVM, we will take a look at the compiled code of the following simple class declaration. int fac(int n) { int result = 1; for (int i=2; i<n; i++) { result = result * i; return result; Compiling and Disassembling % javac Factorial.java % javap -c -verbose Factorial Compiled from Factorial.java class Factorial extends java.lang.object { Factorial(); /* =1, Locals=1, Args_size=1 */ int fac(int); /* =2, Locals=4, Args_size=2 */ Method Factorial() 0 aload_0 1 invokespecial #1 <Method java.lang.object()> 4 return

6 Compiling and Disassembling... // address: Method int fac(int) // stack: this n result i 0 iconst_1 // stack: this n result i 1 1 istore_2 // stack: this n result i 2 iconst_2 // stack: this n result i 2 3 istore_3 // stack: this n result i 4 goto 14 7 iload_2 // stack: this n result i result 8 iload_3 // stack: this n result i result i 9 imul // stack: this n result i result*i 10 istore_2 // stack: this n result i 11 iinc 3 1 // stack: this n result i 14 iload_3 // stack: this n result i i 15 iload_1 // stack: this n result i i n 16 if_icmplt 7 // stack: this n result i 19 iload_2 // stack: this n result i result 20 ireturn.class package Factorial.super java/lang/object Writing Factorial in jasmin Jasminis a Assembler Interface. It takes ASCII descriptions for classes, written in a simple assembler-like syntax and using the Virtual Machine instruction set. It converts them into binary class files suitable for loading into a JVM implementation..method package <init>( )V )V.limit stack limit locals 1 aload_0 invokenonvirtual java/lang/object/<init>( )V )V return.end method Writing Factorial in jasmin (continued).method package fac(i)i.limit stack 50.limit locals 4 iconst_1 istore 2 iconst_2 istore 3 Label_1: iload 3 iload 1 if_icmplt Label_4 iconst_0 goto Label_5 Label_4: iconst_1 Label_5: ifeq Label_2 iload 2 iload 3 imul dup istore 2 pop Label_3: iload 3 dup iconst_1 iadd istore 3 pop goto Label_1 Label_2: iload 2 ireturn iconst_0 ireturn.end method 33 6