JVM Overview References Virtual Machine Background JVM: operational view JVM: structural view...

29
JVM Overview References Virtual Machine Background JVM: operational view JVM: structural view Concluding remarks

Transcript of JVM Overview References Virtual Machine Background JVM: operational view JVM: structural view...

JVM Overview

References

Virtual Machine Background

JVM: operational view

JVM: structural view

Concluding remarks

Reading List

Primary: LY99 Chapter 3. Structure of the Java Virtual Machine Venners98 Chapter 5. The Java Virtual Machine GJS96 Chapter 12: Execution

Other references Survey of VM Research 1974

“Virtual machines have finally arrived. Dismissed for a number of years as academic curiosities, they are now seen as cost effective techniques for organizing computer systems…”

Inferno Virtual Machine Oak Intermediate Bytecode Variety of web-sites

What is a virtual machine?

David Gelernter: Truth, beauty, and VMs “A running program is often referred to as a VM

-- a machine that doesn’t exist as a matter of actual physical reality. The virtual machine idea is … most elegant in the history of technology … a crucial step in the evolution of ideas about software.”

an operating systema control program to run multiple operating

systems

Design Goals

abstract enoughclose enough to the hardwarequestion: what is the intended use?

Inferno: run OS codeJVM: run application code

What is the JVM?

Key Distinction

what is the specification?what is the implementation?

object layout is not part of the specification garbage collection is not part of the spec

JVM: View 1

from the language point of viewtrace the lifetime of a virtual machineinvocation, loading-linking, object lifetime,

exit

VM in action

invoked “java Test args”attempts to find class TestVM uses the class loaderLinkInitializeInvoke Test.main

Loading

check whether already loaded if not, invoke the appropriate loader.loadClass internal table is part of the specification?class loader flexibility: prefetch, load a bunchprefetching can be non-transparent!errors, however, need to be reported

separatelyclass loader hooks: defineClass,

findSystemClass, resolveClass

Link

Link = verification, preparation, resolutionVerification: semantic checks, proper symbol

table proper opcodes, good branch targets conservation of stack depth

Preparation: allocation of storage (method tables)

Resolution: resolve symbol references, check access, check concreteness

Resolution: eager vs lazy strategy

Initialization

initialize class variables, static initializersdirect superclass need to be initialized

priorhappens on direct use: method invocation,

construction, field accesssynchronized initializations: state in Class

object check for recursive initializations

Example

class Super {static { System.out.print(“Super “);

}class One {

static { System.out.print(“One “);}class Two extends Super {

static { System.out.print(“Two “);}class Test {

public static void main(String[] args) {One o = null;Two t = new Two();System.out.println((Object)o == (Object)t);

}}

Example

class Super { static int taxi = 1729; }class Sub extends Super {

static { System.out.print(“Sub “);}class Test {

public static void main(String[] args) {System.out.println(Sub.taxi);

}}

Creation of new instances

instance creation expressions: newClass.newInstance()string literals, concatenation operationsorder:

default field values invoke constructor invoke another constructor of this class invoke super’s constructors initialize instance variables execute rest of the constructor

Finalization

invoked just before garbage collectionlanguage does not specify when it is

invokedalso does not specify which threadno automatic invocation of super’s

finalizersvery tricky!

void finalize() { classVariable = field; // field is now reachable}

State Machine

VM Exit

classFinalize similar to object finalizationclass can be unloaded when

no instances exist class object is unreachable

VM exits when: all its threads terminate Runtime.exit or System.exit assuming it is

secure

finalizers can be optionally invoked on all objects just before exit

JVM: View 2

data types, valuesruntime data areasexceptionsinstruction setobject managementsupport for special libraries

Data types and values

corresponds to Java language types byte, short, int, long, char, float, double, boolean returnAddress type is only exception references: concrete value of null left to

implementation

integer sizes: is it too constraining?floating point values: standard and extendedno runtime type information instruction specifies the type of operands

iadd as opposed to fadd

Object Representation

left to the implementationadd extra level of indirection

make garbage collection easier

need pointers to instance data and class data

mutex lockGC state (flags)

Runtime Data Areas

per-thread vs. VM widepc register: per thread, undefined while

executing native methodsVM stack (per-thread)

local variables, partial results method invocation, return can be heap allocated as well as non-

contiguous size can be manipulated by the programmer StackOverflowError vs OutOfMemoryError

Runtime Data Areas

Heap (VM wide) for storing objects assumes no particular GC method heap size can expand, user control exists might cause OutOfMemoryError

Method area (VM wide) runtime constant pool field and method data code logically part of the heap

Native method stacks: how to catch exceptions?

VM Stack Frames

created and destroyed with method invocations local variable array, own operand stack local variable array elements can store a float/int

over-specification? used for parameter passing instance methods pass “this” as 0th argument

operand stack: depth determined at compile-time elements can hold any type

reference to the class’s runtime constant pool symbolic references for dynamic linking

Initialization Methods

specially named<init> for instances

invokespecial instruction can be invoked only on uninitialized instances

<clinit> for classes implicitly invoked

Exceptions

each catch/finally clause is represented as an exception handler

associated with each handler is the code extent

exception handler table is ordered by the compiler

JVM does not enforce strict nesting

Instruction set

variable size instructionone-byte opcode followed by argumentsbyte aligned except for operands of

tableswitch and lookupswitchcompactness vs. performancetypes part of the instruction (iload, fload)use int operations for byte, char, short, int,

referencesome are type-independent (pop, swap)

Instructions

load/storearithmeticconversionobject creation, access fields, load/store

array elements, get array length, type checks

operand stack managementcontrol transfer, method invocation, throwmonitor entry/exit

Threads

notion of prioritiesdoes not specify time-slicingcomplex specification of consistency model

volatiles working memory vs. general store non-atomic longs and doubles

T.start() is native, invokes T.run()

Summary

issues where implementation is not constrained loading of classes -- bad? finalization of objects -- bad? object representation -- good

issues where implementation is over-constrained integer representations? implementation of local variables, expression stacks?

clearly, a JIT does not conform to these specifications

what really is the specification of the JVM is it the bytecode and class-file format?