2. 1 Introduction to Java & Java Virtual Machine 5/12/2001 Hidehiko Masuhara

3. 2 outline characteristics of Java language Java virtual machine –execution model JIT compilation –4 what it does’

4. 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)

5. 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))

6. 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);

7. 6 virtual calls are expensive 12 34 12 34 object p 12 34 12 34 object cp object red class Pointclass ColorPoint draw getX virtual method tables method body p.draw: vtable <- *p m <- *(vtable+0) call m p.draw: vtable <- *p m <- *(vtable+0) call m because they need “double dispatching”

8. 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!)

9. 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) = or

10. 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

11. 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 optimized by inlinig

12. 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 structure move(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 optimized move become incorrect when a subclass is loaded

13. 12 virtual machine execution model of Java source (text) compiler CPU bytecode interpreter bytecode interpreter dynamic loading JIT compiler JIT compiler compiled code compiled code JVML verifier bytecode (aka. class file)

14. 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

15. 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); }

16. 15 compilation sample (assembly) > javap -c Power synchronized class Power extends java.lang.Object /* ACC_SUPER bit set */ { int base; int unit; int compute(int); Power(); } Method Power() 0 aload_0 1 invokespecial #3 4 return > javap -c Power synchronized class Power extends java.lang.Object /* ACC_SUPER bit set */ { int base; int unit; int compute(int); Power(); } Method Power() 0 aload_0 1 invokespecial #3 4 return Method int compute(int) 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 8 ireturn 9 aload_0 10 getfield #4 13 aload_0 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 20 imul 21 ireturn Method int compute(int) 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 8 ireturn 9 aload_0 10 getfield #4 13 aload_0 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 20 imul 21 ireturn type info. constructor the method

17. 16 heap execution model of JVML p.setX(..) p.move(...) main(...) stack 123 Point X=10,y=3 Point X=10,y=3 local vars.op. stack ColorPoint X=10,y=3 c=Red ColorPoint X=10,y=3 c=Red a frame (activation record) array of Point fields are named op. stack: tentative, operands for VM inst. & for method invocation local vars.: mutable, valid through an invocation

18. 17 VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 8 ireturn 9 aload_0 10 getfield #4 13 aload_0 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 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 Method int compute(int)

19. 18 VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 8 ireturn 9 aload_0 10 getfield #4 13 aload_0 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 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

20. 19 VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 8 ireturn 9 aload_0 10 getfield #4 13 aload_0 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 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

21. 20 VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 8 ireturn 9 aload_0 10 getfield #4 13 aload_0 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 20 imul 21 ireturn this n 1 base this n-1 base 9 10 13 14 15 16

22. 21 VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 8 ireturn 9 aload_0 10 getfield #4 13 aload_0 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 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

23. 22 VM instructions 0 iload_1 1 ifne 9 4 aload_0 5 getfield #6 8 ireturn 9 aload_0 10 getfield #4 13 aload_0 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 20 imul 21 ireturn this n-1 base r v 17 20 21

24. 23 implementations of JVMs bytecode interpreter JIT compiler –as a traditional compiler –as an optimizing compiler –as a JIT compiler

25. 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

26. 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

27. 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

28. 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)

29. 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

30. 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!

31. 30 参考文献 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. 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