1 Continuation Join Points Yusuke Endoh, Hidehiko Masuhara, Akinori Yonezawa (University of Tokyo)
1 Introduction to Java & Java Virtual Machine 5/12/2001 Hidehiko Masuhara.
-
Upload
sophia-moody -
Category
Documents
-
view
226 -
download
2
Transcript of 1 Introduction to Java & Java Virtual Machine 5/12/2001 Hidehiko Masuhara.
1
Introduction toJava & Java Virtual Machine
5/12/2001
Hidehiko Masuhara
2
outline
• characteristics of Java language
• Java virtual machine– execution model
• JIT compilation– 4 what it does’
3
characteristics of the Java language
• virtual machine (VM) based implementation
• object-oriented (OO)• automatic memory management (GC)• thread safe libraries• dynamic class loading• security mechanisms
(incl. bytecode verification)
4
virtual machine based implementation
• not a new idea!
• advantages– compact object code
(cf. embedded systems)– multi-platform execution
(cf. write once, XXX everywhere)
• disadvantages– overheads
(e.g., p-code (late 70’s), Smalltalk (80’s), Self (late 80’s), .Net (2000’s))
5
object-oriented
• encapsulation
• overriding
• reuse
• dynamic dispatch(virtual call)
class Point { int x,y; draw(Graphics g) { g.putPixel(x,y);}}
class Point { int x,y; draw(Graphics g) { g.putPixel(x,y);}}
class ColorPoint extends Point {
Color c; draw(Graphics g) { g.setColor(c); super.draw(g);}}
class ColorPoint extends Point {
Color c; draw(Graphics g) { g.setColor(c); super.draw(g);}}
Point p;p.draw(g);Point p;p.draw(g);
6
virtual calls are expensive
12
34
12
34
object p
12
34
12
34
object cp
object red
class Point class ColorPoint
drawdraw drawdraw
getXgetX
virtual method tables
method body
p.draw:vtable <- *pm <- *(vtable+0)call m
p.draw:vtable <- *pm <- *(vtable+0)call m
because they need “double
dispatching”
7
automatic memory management (GC)
memory for objects & classes are automatically reclaimed
• pros. easy and safe– no more worry about memory corruption
• cons. extra overheads– esp. in Java;
tend to use fine-grained objects
(you already know!)
8
thread safe libraries
standard classes ensures serialized behavior
• how to ensure?lock the object
around method execution
• problem: overuse of lock operations
Thread1:ctr.inc(1)Thread1:ctr.inc(1)
Thread2:ctr.inc(2)Thread2:ctr.inc(2)
ctr.inc(1);ctr.inc(2)ctr.inc(1);ctr.inc(2)
ctr.inc(1);ctr.inc(2)ctr.inc(1);ctr.inc(2)= or
9
dynamic class loading
• class is loaded at its first object creation• also can manually
load classes(eg.,DLL, SO)
• pros.– faster startup– smaller footprint
• cons.– make analysis difficult
class Word { DocWin[] docs; help(Topic t) { Kairu k=new ...; }}
class Word { DocWin[] docs; help(Topic t) { Kairu k=new ...; }}
class Kairu is not loaded until help is called
10
class Point { int x; getX() { return this.x; } setX(int newX) { this.x = newX; } move(Point offset) { setX(this.getX() + offset.getX()); }}
class Point { int x; getX() { return this.x; } setX(int newX) { this.x = newX; } move(Point offset) { setX(this.getX() + offset.getX()); }}
dynamic loading makes analysis difficult
• because optimizations rely on the structure of class hierarchy
move(Point offset) { this.x = this.x + offset.x; }move(Point offset) { this.x = this.x + offset.x; }
can be optimizedby inlinig
11
class Point { int x; getX() { return this.x; } setX(int newX) { this.x = newX; } move(Point offset) { setX(this.getX() + offset.getX()); }}
class Point { int x; getX() { return this.x; } setX(int newX) { this.x = newX; } move(Point offset) { setX(this.getX() + offset.getX()); }}
dynamic loading makes analysis difficult
• because optimizations rely on the structure of class hierarchy
• dynamic loading changes the structuremove(Point offset) { this.x = this.x + offset.x; }move(Point offset) { this.x = this.x + offset.x; }
class DPoint extends Point { getX() { return this.x +random(); }}
class DPoint extends Point { getX() { return this.x +random(); }}
DPoint can’t inherit move
DPoint can’t inherit move
optimized move become incorrect
optimized move become incorrect
when a subclass is loaded
12
virtual machine
execution model of Java
source(text) compiler
CPU
bytecodeinterpreterbytecodeinterpreter
dynamicloading
JITcompiler
JITcompiler
compiledcode
compiledcode
JVML
verifier
bytecode(aka. class file)
13
introduction to JVML
• a VML designed for Java language• characteristics
– rigidly defined (vs. previous counterparts)– typed: can check type safety– not a native machine code
• object manipulations are primitive• infinite number of registers
(local variables)• operand stack
14
compilation sample (source)
class Power {
int base, unit;
int compute(int n) {
if (n==0) return this.unit;
else return this.base *
this.compute(n-1);
}
}
class Power {
int base, unit;
int compute(int n) {
if (n==0) return this.unit;
else return this.base *
this.compute(n-1);
}
}
15
compilation sample (assembly)
> javap -c Powersynchronized class Power e
xtends java.lang.Object /* ACC_SUPER bit set */{ int base; int unit; int compute(int); Power();}
Method Power()0 aload_01 invokespecial #3 <Method
java.lang.Object()>4 return
> javap -c Powersynchronized class Power e
xtends java.lang.Object /* ACC_SUPER bit set */{ int base; int unit; int compute(int); Power();}
Method Power()0 aload_01 invokespecial #3 <Method
java.lang.Object()>4 return
Method int compute(int) 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 <Field int
unit> 8 ireturn 9 aload_010 getfield #4 <Field int
base>13 aload_014 iload_115 iconst_116 isub17 invokevirtual #5 <Metho
d int compute(int)>20 imul21 ireturn
Method int compute(int) 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 <Field int
unit> 8 ireturn 9 aload_010 getfield #4 <Field int
base>13 aload_014 iload_115 iconst_116 isub17 invokevirtual #5 <Metho
d int compute(int)>20 imul21 ireturn
type info.
constructor the method
16
heap
execution model of JVML
p.setX(..)
p.move(...)
main(...)
stack
123123
PointX=10,y=3
PointX=10,y=3
local vars. op. stack
ColorPointX=10,y=3
c=Red
ColorPointX=10,y=3
c=Red
a frame (activation record)
array of Point• fields are named• op. stack: tentative, operan
ds for VM inst. & for method invocation
• local vars.: mutable, valid through an invocation
17
VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 <Field int
unit> 8 ireturn 9 aload_010 getfield #4 <Field int
base>13 aload_014 iload_115 iconst_116 isub17 invokevirtual #5 <Metho
d int compute(int)>20 imul21 ireturn
• when a method is invoked,– local var.#0: “this”– local var.#1..:
arguments
• push int val. of lv#1 on op. stack
• pop int val., if it<>0 then jump to 9
Method int compute(int)
18
VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 <Field int
unit> 8 ireturn 9 aload_010 getfield #4 <Field int
base>13 aload_014 iload_115 iconst_116 isub17 invokevirtual #5 <Metho
d int compute(int)>20 imul21 ireturn
• push addr. val. in lv#0 (this) on op. stack
• pop addr. val off op. stack, read field “unit”, push the result on op. stack
• return from the method
19
VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 <Field int
unit> 8 ireturn 9 aload_010 getfield #4 <Field int
base>13 aload_014 iload_115 iconst_116 isub17 invokevirtual #5 <Metho
d int compute(int)>20 imul21 ireturn
• push “this”• read “base” field• push “this”• push “n”• push value 1• pop val. of “n” & 1 of
f stack, subtract, and push result
20
VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 <Field int
unit> 8 ireturn 9 aload_010 getfield #4 <Field int
base>13 aload_014 iload_115 iconst_116 isub17 invokevirtual #5 <Metho
d int compute(int)>20 imul21 ireturn
this
this
n
1
base
this
n-1
base
9
10
13
14
15 16
21
VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 <Field int
unit> 8 ireturn 9 aload_010 getfield #4 <Field int
base>13 aload_014 iload_115 iconst_116 isub17 invokevirtual #5 <Metho
d int compute(int)>20 imul21 ireturn
• method call– pop obj. & int off the o
p. stack, – call method “compute”
of the obj. with int value
– push return value
• pop 2 values, multiply, push result
• return from method
22
VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 <Field int
unit> 8 ireturn 9 aload_010 getfield #4 <Field int
base>13 aload_014 iload_115 iconst_116 isub17 invokevirtual #5 <Metho
d int compute(int)>20 imul21 ireturn
this
n-1
base
r
base v
17
20
21
23
implementations of JVMs
• bytecode interpreter
• JIT compiler– as a traditional compiler– as an optimizing compiler– as a JIT compiler
24
bytecode interpreter simulates the machine
• it’s expensive• VM core:
– read bytecode– dispatch– compute
while (true) { code = prog[pc++]; switch (code) { LOAD: n=prog[pc++]; v=local[n]; opstack[sp++]; STORE: ... ... }}
while (true) { code = prog[pc++]; switch (code) { LOAD: n=prog[pc++]; v=local[n]; opstack[sp++]; STORE: ... ... }}
alternative:“threaded execution” = a very light weight JIT compilation
25
JIT does what compilers do
but does at run-time!
(still not new; cf. Smalltalk & Self)
• register allocation (to local vars & op. stacks)
• translate VM instrs. to native instrs.
• instruction scheduling
26
JIT does optimizing compilers do
• method inlining (cf. Self)
• common subexpression elimination
• loop unrolling
• array boundary check deletion
• etc.
but they must be quick enough
27
JIT does more than traditional compilers do
• stack allocation of temporary objects* up to programmer in C++
** similar to region analysis in FPs
• eliminate lock/unlocks when accessing private objects
• optimistic type customization (cf. Self)(with revoke mechanism)
28
JIT does what only JIT does
adaptive or mixed execution• several execution modes
– interpretive– quick compilation, no optimization– ...– slow but highly optimizing compilation
• profile to find “hotspots” & more optimize them
• faster startup, smaller memory footprint
29
summary
• Java has many advanced language features– good for
programmers– challenge for
implementers
• JVM– key to Java’s
portability– performance
• JIT compilers– has most features of
modern optimizing compilers
– do more than that!
30
参考文献• L. Peter Deutsch and Allan M. Schiffman. Efficient implementation of the Smallta
lk-80 system. In Conference Record of the 11th Annual ACM Symposium on Principles of Programming Languages (POPL'84), pages 297-302, Salt Lake City, Jan 1984.
• J. Dolby and A. A. Chien. An evaluation of automatic object inline allocation techniques. In Proceedings of Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), 1998.
• Tim Lindholm and Frank Yellin. The Java Virtual Machine Specification. Addison-Wesley, 1997.
• David Ungar and Randall B. Smith. Self: The power of simplicity. In Norman Meyrowitz, editor, Proceedings of Object-Oriented Programming Systems, Languages, and Applications, volume 22(12) of ACM SIGPLAN Notices, pages 227-242, Orlando, FL, October 1987. ACM.
• OOPSLA (Object-Oriented Programming Systems) / PLDI (Programming Language Design and Implementation) / POPL (Principles of Programming Languages) / Java Grande Workshop / Java Virtual Machine Conference