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()); }}


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



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




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




• 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





• 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





• 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





this

this

n

1

base

this

n-1

base

9

10

13

14

15 16

21





• 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





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

1 introduction to java & java virtual machine 5/12/2001 hidehiko masuhara

Documents