Date post: | 15-Dec-2015 |
Category: |
Documents |
Upload: | mandy-newlove |
View: | 254 times |
Download: | 1 times |
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
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}
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?