Download JVM - Webcourse

The JVM
oop
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
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.
Program
in other
Lang.
Compiler
class
files
Java
Compiler
class
files
Program
in Java
Lang.
oop
Compiler
Other
Binary
format
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
Basic JVM Components
The Java Virtual Machine
Program
Class
files
The Java
API’s
class files
Class
loader
Execution
engine
Native methods invocation
Host operating system
oop
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
Typed Assembly
 High Level Language
f(int a, int b, int c, int d) {
return (a + b) *c - d;
}
 Class
0:
1:
2:
3:
4:
5:
6:
7:
oop
iload_1
iload_2
iadd
iload_3
imul
iload 4
isub
ireturn
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
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
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
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
JVM Instruction Set
1.
2.
3.
4.
5.
6.
7.
oop
Arithmetic
Stack Manipulation
Variables and Constants
Conversions
Arrays
Objects (methods and fields)
Control
Some Instructions
 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
oop
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
Some More Instructions
 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…
oop
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
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
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
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
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
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
The Java Programming Environment
Compile time environment
A.Java
B.Java
C.Java
oop
B.class
A.class
B.class
C.class
Java
Virtual
Machine
Java
Compiler
A.class
run time environment
C.class
Object class
String class