Introduction to Java & Java Virtual Machine

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. 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);}} object-oriented • encapsulation • overriding • reuse • dynamic dispatch(virtual call) Point p;p.draw(g);

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

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) Thread2: 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 manuallyload classes(eg.,DLL, SO) • pros. • faster startup • smaller footprint • cons. • make analysis difficult class Word { DocWin[] docs; help(Topic t) { Kairu k=new ...; } } class Kairu is not loaded until help is called

10. dynamic loading makes analysis difficult • because optimizations rely on the structure of class hierarchy move(Point offset) { this.x = this.x + offset.x; } class Point { int x; getX() { return this.x; } setX(int newX) { this.x = newX; } move(Point offset) { setX(this.getX() + offset.getX()); } } can be optimized by inlinig

11. dynamic loading makes analysis difficult DPoint can’t inherit move optimized move become incorrect • because optimizations rely on the structure of class hierarchy • dynamic loading changes the structure move(Point offset) { this.x = this.x + offset.x; } class Point { int x; getX() { return this.x; } setX(int newX) { this.x = newX; } move(Point offset) { setX(this.getX() + offset.getX()); } } class DPoint extends Point { getX() { return this.x +random(); } } when a subclass is loaded

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

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) • operandstack

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

15. > 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 <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 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 <Method int compute(int)> 20 imul 21 ireturn compilation sample (assembly) type info. the method constructor

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

17. 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 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 VM instructions Method int compute(int)

18. 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 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 VM instructions

19. 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 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 VM instructions

20. 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 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 <Method int compute(int)> 20 imul 21 ireturn n-1 this base VM instructions 15 1 16 14 n 9 13 this this 10 base

21. 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 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 VM instructions

22. 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 14 iload_1 15 iconst_1 16 isub 17 invokevirtual #5 <Method int compute(int)> 20 imul 21 ireturn n-1 this base VM instructions 17 r 20 base v 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: ... ... } } 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 optimizingcompilers 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 thantraditional 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. 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! summary

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