The JVM

1. The JVM oop

2. What’s a JVM • A computing machine (just like 8086, but not produced by Intel) • Abstract: machine is specified in a book. • Concrete: anyone can implement • Input: • A “class” file • a binary file with lots of numbers and instructions. • A search path (to find more class files) • Output • The “execution” of the class file. • How? • It is all in The Java Virtual Machine Specification, by Tim Lindholm and Frank Yellin • Start with? • A method named “main” in a given class file. • The method must have certain properties • Continue execution in other methods as necessary. oop

3. Class File? • The binary form for Java programs • Represents a complete description of one Java class or interface • Platform independent – bytecodes are the machine language of the JVM • Not necessarily linked to the java language: Java Program in Java Lang. Compiler class files Java Program in other Lang. Compiler class files Program in Java Lang. Compiler Other Binary format oop

4. Class File Structure • Part I: Pool • Maps strings to integers. • Mostly symbolic names. • Part II: instructions for execution • Organized in “methods” • Each reference to another method, or another class file is through a “small integer” (index to the pool) oop

5. Basic JVM Components The Java Virtual Machine Program Classfiles Classloader The JavaAPI’sclass files Executionengine Native methods invocation Host operating system oop

6. Semantics of the Abstract Machine • Low level, Assembly Like: • no expression such as (a + b) *c • No ordinary memory addressing (cannot access address 1000) • Use symbolic names, as defined in the pool. • Garbage collected! • No registers (stack semantics) • To do (a+b)*c: • Push a • Push b • Add • Push c • Mult • Scratch variables (used for storing arguments and local variables) • Each method defines how many it needs oop

7. Typed Assembly • High Level Language • Class f(int a, int b, int c, int d) { return (a + b) *c - d; } • 0: iload_1 • 1: iload_2 • 2: iadd • 3: iload_3 • 4: imul • 5: iload 4 • 6: isub • 7: ireturn oop

8. JVM Types • Similar (but not identical) to Java • Primitive data types. • byte: one byte • short: two bytes • int: four bytes • long: eight bytes (2 entries on stack) • float: four bytes • double: eight bytes (2 entries on stack) • char: two bytes • Reference types: • Class reference • Interface reference • Array reference oop

9. Object Oriented Assembly • No ordinary memory model • All memory references are through fields. • A class file defines a class, just like any other object oriented language: • Class has: • Fields (also static) • Methods (also static) • Constructors, • ... • Multi-threaded language • Exception support • So that constructors can fail oop

10. Memory Model • Areas: • Stacks (no single stack, since we have threads) • Usually organized as a linked list • Elements: method frames which include • Local Variables Array (LVA) • Operand stack (OS) • Accessible by push/pop instructions. • Garbage collected • Heap • All objects and all arrays • No object is allocated in the stack • Each object is associated with a class stored in the method area • Garbage collected. • Method area • Information about types, constant pool, fields and method i • Inaccessible to programmer • Garbage collected oop

11. Typed Instructions • Most JVM instructions are typed ! • Enables bytecode verification at load time • “xload v” (x ∈ {a, i, l, f, d}) • Loads (i.e. pushes) a variable v on the stack • The prefix specifies the type • If x = l (long) or x = d (double) then two words are pushed • Otherwise, the type annotation is only for type checking • “xstore” • Stores in an array (the array, the index and the stored value are popped from the operand stack) • This is the first successful attempt to bring type safety to a lower level language oop

12. Arithmetic Stack Manipulation Variables and Constants Conversions Arrays Objects (methods and fields) Control JVM Instruction Set oop

13. Arithmetic: iadd, isub, imul, idiv, ineg, irem Bitwise (ints & longs) : iand, ior, ixor, ishl, ishr, iushr Stack Manipulation: Swap, pop, dup Versions that work on two words at a time: pop2, dup2 Load and Store: Locals -> Stack: [i/f/l/d/a]load n Stack ->Locals: [i/f/l/d/a]store n Specialized load and store instructions: iload_1 pushes int from local variable position one onto stack Some Instructions oop

14. Some More Instructions • Type Conversions (casts) • The JVM pops the value at the top of the stack, converts it, and pushes the result back onto the stack. • i2f converts int to float • Instructions for Arrays • newarrray <type>: Allocates an array of primitives • anewarrray <classname>: Allocates an array of references • Instructions for Objects • new <classname> • Followed (separately) by call to constructor, • getfield <full-fieldname> <field-type> • invokevirtual <full-methodname> <method-type> • Stack: ... object-reference params -> ... returned-value oop

15. Control Instructions All control structures (if, switch, while, for, break, continue) are translated to labels and branches to labels Labels have method scope Labels are translated into offsets from the beginning of the branch instruction to the beginning of the labeled instruction goto, if_icmpeq, if_acmpeq, ifnull… Some More Instructions oop

16. Type Checking Strategies • None (e.g., PDP11 assembly) • Compile time only (e.g., C++) • Runtime only (e.g., Smalltalk) • Compile time and runtime (e.g., C#) • Load time: JVM • Rationale: • No compilation process • Any hacker can mess with the bytecodes. oop

17. Type Checking in the JVM • At each code location (byte offset of the method code) • The number of cells used in LVA and OS is known. • Each cell has one, and only one type • Primitive/reference. • Only instructions that treat the cells “as they should” are allowed: • No arithmetical operations on characters. • Cannot push two integers and then pop a long. • Only apply methods if the object knows about them. oop

18. Verification • When? • Mainly during the load and link process • Why? • No guarantee that the class file was generated by a Java compiler • Enhance runtime performance • Examples • There are no operand stack overflows or underflows. • All local variable uses and stores are valid. • The arguments to all the Java Virtual Machine instructions are of valid types. oop

19. Verification Process • Pass 1 – when the class file is loaded • The file is properly formatted, and all its data is recognized by the JVM • Pass 2 – when the class file is linked • All checks that do not involve instructions • final classes are not subclassed, final methods are not overridden. • Every class (except Object) has a superclass. • All field references and method references in the constant pool have valid names, valid classes, and a valid type descriptor. oop

20. Verification Process – cont. • Pass 3 – still during linking • Data-flow analysis on each method . Ensure that at any given point in the program, no matter what code path is taken to reach that point: • The operand stack is always the same size and contains the same types of objects. • No local variable is accessed unless it is known to contain a value of an appropriate type. • Methods are invoked with the appropriate arguments. • Fields are assigned only using values of appropriate types. • All opcodes have appropriate type arguments on the operand stack and in the local variables • Pass 4 - the first time a method is actually invoked • a virtual pass whose checking is done by JVM instructions • The referenced method or field exists in the given class. • The currently executing method has access to the referenced method or field. oop

21. JVM in Java Architecture • Java’s architecture main technologies: • The Java programming language • Source files • The Java class file format • Compiled files • The Java API • Provide access to system resources • The Java virtual machine • Runs the class files oop

22. The Java Programming Environment Compile time environment run time environment A.Java B.Java C.Java A.class B.class C.class JavaCompiler JavaVirtualMachine A.class B.class C.class Object class String class oop