Introduction to Java Java Virtual Machine 5122001 Hidehiko

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. put. Pixel(x, y); }} class Color. Point extends Point { Color c; draw(Graphics g) { g. set. Color(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 Color. Point object p object cp 12 12 34 34 draw get. X 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 Thread 1: ctr. inc(1) Thread 2: 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 { Doc. Win[] 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; get. X() { return this. x; } set. X(int new. X) { this. x = new. X; } move(Point offset) { set. X(this. get. X() + offset. get. X()); } } 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; get. X() { return this. x; } set. X(int new. X) { this. x = new. X; } move(Point offset) { set. X(this. get. X() + offset. get. X()); } } move(Point offset) { this. x = this. x + offset. x; } class DPoint extends Point { get. X() { return this. x +random(); } } when a subclass is loaded 11

execution model of Java source (text) compiler bytecode (aka. class file) dynamic loading virtual machine bytecode interpreter JVML 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 Color. Point X=10, y=3 c=Red Point X=10, y=3 heap p. set. X(. . ) p. move(. . . ) main(. . . ) stack 123 local vars. op. stack a frame (activation record) 16

VM instructions Method int compute(int) 0 1 4 5 8 9 10 13 14 15 16 17 20 21 iload_1 ifne 9 aload_0 getfield #6 <Field int unit> ireturn aload_0 getfield #4 <Field int base> aload_0 iload_1 iconst_1 isub invokevirtual #5 <Method int compute(int)> imul 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 8 9 10 13 14 15 16 17 20 21 iload_1 ifne 9 aload_0 getfield #6 <Field int unit> ireturn aload_0 getfield #4 <Field int base> aload_0 iload_1 iconst_1 isub invokevirtual #5 <Method int compute(int)> imul 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 8 9 10 13 14 15 16 17 20 21 iload_1 ifne 9 aload_0 getfield #6 <Field int unit> ireturn aload_0 getfield #4 <Field int base> aload_0 iload_1 iconst_1 isub invokevirtual #5 <Method int compute(int)> imul 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 8 9 10 13 14 15 16 17 20 21 iload_1 ifne 9 aload_0 getfield #6 <Field int unit> ireturn aload_0 getfield #4 <Field int base> aload_0 iload_1 iconst_1 isub invokevirtual #5 <Method int compute(int)> imul ireturn 9 this 15 1 14 n 13 this 10 base 16 n-1 this base 20

VM instructions 0 1 4 5 8 9 10 13 14 15 16 17 20 21 iload_1 ifne 9 aload_0 getfield #6 <Field int unit> ireturn aload_0 getfield #4 <Field int base> aload_0 iload_1 iconst_1 isub invokevirtual #5 <Method int compute(int)> imul 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 8 9 10 13 14 15 16 17 20 21 iload_1 ifne 9 aload_0 getfield #6 <Field int unit> ireturn aload_0 getfield #4 <Field int base> aload_0 iload_1 iconst_1 isub invokevirtual #5 <Method int compute(int)> imul 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 11 th 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 30