Download class Point

Introduction to
Java & Java Virtual Machine
5/12/2001
Hidehiko Masuhara
1
outline
• characteristics of Java language
• Java virtual machine
– execution model
• JIT compilation
– 4 what it does’
2
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)
3
virtual machine based
implementation
• not a new idea!
• advantages
(e.g., p-code (late 70’s), Smalltalk (80’s),
Self (late 80’s), .Net (2000’s))
– compact object code
(cf. embedded systems)
– multi-platform execution
(cf. write once, XXX everywhere)
• disadvantages
– overheads
4
object-oriented
•
•
•
•
encapsulation
overriding
reuse
dynamic dispatch
(virtual call)
Point p;
p.draw(g);
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);}}
5
virtual calls are expensive
virtual method tables
because they need
“double
dispatching”
p.draw:
vtable <- *p
m <- *(vtable+0)
call m
class Point
class ColorPoint
object p object cp
12
12
34
34
draw
draw
getX
object red
method body
6
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!)
7
thread safe libraries
standard classes ensures
serialized behavior
Thread1:
ctr.inc(1)
Thread2:
ctr.inc(2)
=
ctr.inc(1);
ctr.inc(2)
or
ctr.inc(1);
ctr.inc(2)
• how to ensure?
lock the object
around method execution
• problem: overuse of lock operations
8
dynamic class loading
• class is loaded at its first object creation
• also can manually
class Word {
DocWin[] docs;
load classes
help(Topic t) {
(eg.,DLL, SO)
Kairu k=new ...;
}
• pros.
– faster startup
– smaller footprint
}
• cons.
– make analysis difficult
class Kairu is
not loaded until
help is called
9
dynamic loading makes
analysis difficult
• because optimizations rely on the
structure of class hierarchy
class Point {
int x;
getX() { return this.x; }
setX(int newX) { this.x = newX; }
move(Point offset)
{ setX(this.getX() + offset.getX()); }
}
move(Point offset)
{ this.x = this.x + offset.x; }
can be optimized
by inlinig
10
dynamic loading makes
analysis difficult
•
optimized move
DPoint
can’toptimizations rely
because
on the
become
inherit move
incorrect
structure of class hierarchy
• dynamic loading changes the structure
class Point {
int x;
getX() { return this.x; }
setX(int newX) { this.x = newX; }
move(Point offset)
{ setX(this.getX() + offset.getX()); }
}
move(Point offset)
{ this.x = this.x + offset.x; }
class DPoint extends Point {
getX() { return this.x
+random(); }
}
when a subclass is loaded
11
execution model of Java
source
(text)
compiler
bytecode
(aka. class file)
JVML
dynamic
loading
virtual machine
bytecode
interpreter
verifier
JIT
compiler
compiled
code
CPU
12
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
13
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);
}
}
14
compilation sample
(assembly)
> javap -c Power
synchronized class Power
extends java.lang.Object
/* ACC_SUPER bit set */
{
int base;
type info.
int unit;
int compute(int);
Power();
}
Method Power() constructor
0 aload_0
1 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_0
10 getfield #4 <Field int
base>
13 aload_0
the method
14 iload_1
15 iconst_1
16 isub
17 invokevirtual #5
<Method int
compute(int)>
20 imul
21 ireturn
15
execution model of JVML
• fields are named
• op. stack: tentative,
operands for VM inst. & for
method invocation
• local vars.: mutable, valid
through an invocation
array of Point
ColorPoint
X=10,y=3
c=Red
Point
X=10,y=3
heap
p.setX(..)
p.move(...)
main(...)
stack
123
local vars.
op. stack
a frame (activation record)
16
VM instructions
Method int compute(int)
0
1
4
5
iload_1
ifne 9
aload_0
getfield #6 <Field int
unit>
8 ireturn
9 aload_0
10 getfield #4 <Field int
base>
13 aload_0
14 iload_1
15 iconst_1
16 isub
17 invokevirtual #5
<Method int
compute(int)>
20 imul
21 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
17
VM instructions
0
1
4
5
iload_1
ifne 9
aload_0
getfield #6 <Field int
unit>
8 ireturn
9 aload_0
10 getfield #4 <Field int
base>
13 aload_0
14 iload_1
15 iconst_1
16 isub
17 invokevirtual #5
<Method int
compute(int)>
20 imul
21 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
18
VM instructions
0
1
4
5
iload_1
ifne 9
aload_0
getfield #6 <Field int
unit>
8 ireturn
9 aload_0
10 getfield #4 <Field int
base>
13 aload_0
14 iload_1
15 iconst_1
16 isub
17 invokevirtual #5
<Method int
compute(int)>
20 imul
21 ireturn
•
•
•
•
•
•
push “this”
read “base” field
push “this”
push “n”
push value 1
pop val. of “n” & 1
off stack, subtract,
and push result
19
VM instructions
0
1
4
5
iload_1
ifne 9
aload_0
getfield #6 <Field int
unit>
8 ireturn
9 aload_0
10 getfield #4 <Field int
base>
13 aload_0
14 iload_1
15 iconst_1
16 isub
17 invokevirtual #5
<Method int
compute(int)>
20 imul
21 ireturn
9
this
15
1
14
n
13 this
10 base
16
n-1
this
base
20
VM instructions
0
1
4
5
iload_1
ifne 9
aload_0
getfield #6 <Field int
unit>
8 ireturn
9 aload_0
10 getfield #4 <Field int
base>
13 aload_0
14 iload_1
15 iconst_1
16 isub
17 invokevirtual #5
<Method int
compute(int)>
20 imul
21 ireturn
• method call
– pop obj. & int off the
op. stack,
– call method
“compute” of the obj.
with int value
– push return value
• pop 2 values,
multiply, push result
• return from method
21
VM instructions
0
1
4
5
iload_1
ifne 9
aload_0
getfield #6 <Field int
unit>
8 ireturn
9 aload_0
10 getfield #4 <Field int
base>
13 aload_0
14 iload_1
15 iconst_1
16 isub
17 invokevirtual #5
<Method int
compute(int)>
20 imul
21 ireturn
n-1
this
base
17
r
base
20
v
21
22
implementations of JVMs
• bytecode interpreter
• JIT compiler
– as a traditional compiler
– as an optimizing compiler
– as a JIT compiler
23
bytecode interpreter
simulates the machine
• it’s expensive
• VM core:
– read bytecode
– dispatch
– compute
alternative:“threaded
execution” = a very light
weight JIT compilation
while (true) {
code = prog[pc++];
switch (code) {
LOAD:
n=prog[pc++];
v=local[n];
opstack[sp++];
STORE: ...
...
}
}
24
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
25
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
26
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)
27
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
28
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!
29
参考文献
•
•
•
•
•
L. Peter Deutsch and Allan M. Schiffman. Efficient implementation of the
Smalltalk-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. AddisonWesley, 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
30