Java Technologies. Lecture IV. Valdas Rapševičius

Transcription

1 Preparation of the material was supported by the project Increasing Internationality in Study Programs of the Department of Computer Science II, project number VP1 2.2 ŠMM-07-K , funded by The European Social Fund Agency and the Government of Lithuania. Java Technologies Lecture IV Valdas Rapševičius Vilnius University Faculty of Mathematics and Informatics

2 Session Outline This session is about Java Virtual Machine. Period. You will learn how to get from.java to.class to.asm We will dive into the HotSpot JVM internals to understand indepth the concepts of Garbage Collection JIT Compiler JNI All what will be said during the session you have to be able to look at and try by yourself by using JVM options and other JVM tools Your program is slow? No problem, after the session you should be able to find why?? 2

3 JVM The Java Virtual Machine is the cornerstone of the Java platform Responsible for hardware- and operating system-independence the small size of its compiled code its ability to protect users from malicious programs. Class file structure and similar specs are defined in The Java Virtual Machine Specification Implementations: HotSpot (Oracle, Free) OpenJDK (Oracle, GNU GPL + linking exceptions) Kaffe (GNU GPL) J9 (IBM, IBM EULA) dozens of others 3

4 Java code to JVM The Java virtual machine is an abstract computing machine Like a real computing machine, it has an instruction set and manipulates various memory areas at runtime. The Java virtual machine knows nothing of the Java programming language! only of a particular binary format, the class file format. A class file contains Java virtual machine instructions (or bytecodes) and a symbol table, as well as other ancillary information 4

5 Java code to JVM 5

6 JVM:.class File Structure A Java class file is consist of 10 basic sections: Magic Number: 0xCAFEBABE Version of Class File Format: the minor and major versions of the class file Constant Pool: Pool of constants for the class Access Flags: for example whether the class is abstract, static, etc. This Class: The name of the current class Super Class: The name of the super class Interfaces: Any interfaces in the class Fields: Any fields in the class Methods: Any methods in the class Attributes: Any attributes of the class (for example the name of the sourcefile, etc.) 6

7 JVM: Example (1) public class MyClass { public int sum(int i, int j) { return i + j; public static void main(string [] args) { int i = 1; int j = 2; MyClass m = new MyClass(); System.out.format("Sum = %d%n", m.sum(i, j)); ~ $ javac MyClass.java # compiles and creates MyClass.class 7

8 JVM: Example (2) ~ $ xxd ManoKlase.class : cafe babe a ( : a : a a0a 001b 001c 0a00 1d : 1e c69 6e69 743e <init>...()V : f f 4c69 6e65 4e75...Code...LineNu : 6d c d61 mbertable...suma : d e01...(II)I...main : b 4c6a f 6c61 6e67 2f53..([Ljava/lang/S : e 673b a53 6f tring;)v...sourc : c e 4d61 6e6f 4b6c 6173 efile...manoklas 00000a0: 652e 6a c00 0a00 0b d61 e.java...ma 00000b0: 6e6f 4b6c f 0c noklase....! c0: 000b d61 203d e Suma = %d%n d0: 6a f6c 616e 672f 4f62 6a java/lang/object 00000e0: 0c00 0e00 0f c "..#.$..% 00000f0: 0c a f6c 616e..&.'...java/lan : 672f d f g/system...out : 154c 6a f69 6f2f e 7453.Ljava/io/PrintS : d3b a f 6c61 tream;...java/la : 6e67 2f49 6e c ng/integer...val : f c6a f ueof...(i)ljava/ : 6c61 6e67 2f49 6e b lang/integer; : 6a f69 6f2f e java/io/printstr 8

9 JVM: Example (3) ~$ javap verbose ManoKlase # disassembles.class file (see next slide) Compiled from "ManoKlase.java" public class ManoKlase extends java.lang.object SourceFile: "ManoKlase.java" minor version: 0 major version: 50 Constant pool: const #1 = Method #6.#20; // java/lang/object."<init>":()v const #2 = class #21; // ManoKlase const #3 = Method #2.#20; // ManoKlase."<init>":()V const #4 = Field #22.#23; // java/lang/system.out:ljava/io/printstream; const #5 = String #24; // Suma = %d%n const #6 = class #25; // java/lang/object const #7 = Method #2.#26; // ManoKlase.suma:(II)I const #8 = Method #27.#28; // java/lang/integer.valueof:(i)ljava/lang/integer; const #9 = Method #29.#30; // java/io/printstream.format:(ljava/lang/string;[ljava/lang/object;)ljava/io ; const #10 = Asciz <init>; const #11 = Asciz ()V; const #12 = Asciz Code; const #13 = Asciz LineNumberTable; const #14 = Asciz suma; const #15 = Asciz (II)I; const #16 = Asciz main; const #17 = Asciz ([Ljava/lang/String;)V; const #18 = Asciz SourceFile; Continued on next slide 9

10 JVM: Example (4) { public ManoKlase(); Code: Stack=1, Locals=1, Args_size=1 0: aload_0 1: invokespecial #1; //Method java/lang/object."<init>":()v 4: return LineNumberTable: line 1: 0 public int suma(int, int); Code: Stack=2, Locals=3, Args_size=3 0: iload_1 1: iload_2 2: iadd 3: ireturn LineNumberTable: line 4: 0 public static void main(java.lang.string[]); Code: Stack=8, Locals=4, Args_size=1 0: iconst_1 1: istore_1 2: iconst_2 3: istore_2 4: new #2; //class ManoKlase 7: dup 8: invokespecial #3; //Method "<init>":()v 11: astore_3 12: getstatic #4; //Field java/lang/system.out:ljava/io/printstream; 15: ldc #5; //String Suma = %d%n 17: iconst_1 18: anewarray #6; //class java/lang/object 21: dup 22: iconst_0 23: aload_3 24: iload_1 25: iload_2 26: invokevirtual #7; //Method suma:(ii)i 29: invokestatic #8; //Method java/lang/integer.valueof:(i)ljava/lang/integer; 32: aastore 33: invokevirtual #9; //Method java/io/printstream.format:(ljava/lang/string;[ljava/lang/object;)ljava/ 36: pop 37: return LineNumberTable: line 8: 0 line 9: 2 line 10: 4 line 11: 12 line 12: 37 10

11 Disassembling Check available options if PrintAssembler exists java -XX:+UnlockDiagnosticVMOptions - XX:+PrintFlagsFinal version Download hsdis library from Put the.so or.dll file close to libjvm.so or jvm.dll or adjust LD_LIBRARY_PATH Run java -XX:+UnlockDiagnosticVMOptions - XX:+PrintAssembly -Xcomp -server -cp. ManoKlase 11

12 HotSpot The Java HotSpot Virtual Machine is a core component of the Java SE platform and it implements the Java Virtual Machine Specification, and is delivered as a shared library in the Java Runtime Environment. Main HotSpot building blocks: JIT compiler, pluggable, client or server. Garbage Collector, pluggable. Runtime, provides basic functionality and core services. 12

13 HotSpot: Runtime Command Line Options VM Life Cycle Management VM Class Loading Byte Code Verification Class Data Sharing Interpreter Exception Handling Synchronization Thread Management C++ Heap Management Java Native Interface VM Fatal Error Handling 13

14 HotSpot: Command Line Options (1) There are three main categories of command line options: Standard command line options are expected to be accepted by all Java Virtual Machine implementations as required by the Java Virtual Machine Specification. [1] Standard command line options are stable between releases. However, it is possible for standard command line options to be deprecated in subsequent releases after the release in which it was first introduced. Nonstandard command line options begin with a -X prefix. Nonstandard command line options are not guaranteed to be supported in all JVM implementations, nor are they required to be supported in all JVM implementations. Nonstandard command line options are also subject to change without notice between subsequent releases of the Java SDK. Developer command line options in the HotSpot VM begin with a XX prefix. Developer command line options often have specific system requirements for correct operation and may require privileged access to system configuration parameters. Like nonstandard command line options, developer command line options are also subject to change between releases without notice. with boolean flags, a + or - before the name of the options indicates a true or false value, respectively, to enable or disable a given HotSpot VM feature or option. options that take an additional argument, those that are nonboolean, tend to be of the form, -XX:OptionName=<N> where <N> is some numeric value. Almost all developer command line options that take an additional argument, accept an integer value along with a suffix of k, m, or g, which are used as kilo-, mega-, or giga- multipliers for the integer value specified. 14

15 HotSpot: Command Line Options (2) Check available options: java -XX:+AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal version 15

16 JVM Runtime: Structure JVM is divided into several components like the stack, the garbage-collected heap, the registers and the method area. Let us see diagram representation of JVM Stack Frame in Java virtual machine stores various method arguments as well as the local variables of any method. Stack also keep track of each an every method invocation. There are three registers that help in stack manipulation: vars, frame, optop. This registers points to different parts of current Stack. There are three sections in Java stack frame: Local Variables. The local variables section contains all the local variables being used by the current method invocation. It is pointed to by the vars register. Execution Environment. The execution environment section is used to maintain the operations of the stack itself. It is pointed to by the frame register. Operand Stack. The operand stack is used as a work space by bytecode instructions. It is here that the parameters for bytecode instructions are placed, and results of bytecode instructions are found. The top of the operand stack is pointed to by the optop register. Method Area where bytecodes reside. The PC points to some byte in the method area. It always keep tracks of the current instruction which is being executed (interpreted). After execution of an instruction, the JVM sets the PC to next instruction. Method area is shared among all the threads of a process. Hence if more then one threads are accessing any specific method or any instructions, synchronization with Monitors is needed. Heap is the Garbage-collected area where the objects in Java programs are stored. Whenever we allocate an object using new operator, the heap comes into picture and memory is allocated from there. 16

17 Garbage Collection Heap storage for objects is reclaimed by an automatic storage management system (typically a garbage collector); objects are never explicitly deallocated. Java Virtual Machine Specification [1] An object is considered garbage when it can no longer be reached from any pointer in the running program. The most straightforward garbage collection algorithms simply iterate over every reachable object. Any objects left over are then considered garbage. The time this approach takes is proportional to the number of live objects, which is prohibitive for large applications maintaining lots of live data. The HotSpot VM uses a generational garbage collector, a well-known garbage collection approach that relies on the following two observations: Most allocated objects become unreachable quickly. Few references from older to younger objects exist. These two observations are collectively known as the weak generational hypothesis, which generally holds true for Java applications. From Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning 17

18 GC: Ergonomics First introduced in J2SE 5.0. The goal of ergonomics is to provide good performance with little or no tuning of command line options by selecting at JVM startup, instead of using fixed defaults the garbage collector, heap size, and runtime compiler This selection assumes that the class of the machine on which the application is run is a hint as to the characteristics of the application (i.e., large applications run on large machines). In addition to these selections is a simplified way of tuning garbage collection. The more general ergonomics is described in the document entitled Ergonomics in the 5.0 Java Virtual Machine. In short: If the system is detected as a server class system (i.e. >2 CPU and 2 GB RAM), the server VM is selected (-server) The garbage collector (GC) is changed from the default serial collector (-XX:+UseSerialGC) to a parallel collector (-XX:+UseParallelGC) Heap size setting: initial heap size: larger of 1/64th of the machine's physical memory on the machine or some reasonable minimum. maximum heap size: Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default maximum heap size was 64MB. Maximum GC pause time goal -XX:MaxGCPauseMillis=<n> Throughput goal -XX:GCTimeRatio=<n> (GC Time : Application time = 1/(1 + n) e.g. - XX:GCTimeRatio=19 (5% of time in GC)) 18

19 GC: Generations At initialization, a maximum address space is virtually reserved but not allocated to physical memory unless it is needed. The complete address space reserved for object memory can be divided into the young and tenured generations. The young generation consists of eden and two survivor spaces. Most objects are initially allocated in eden. One survivor space is empty at any time, and serves as the destination of any live objects in eden and the other survivor space during the next copying collection. Objects are copied between survivor spaces in this way until they are old enough to be tenured (copied to the tenured generation). A third generation closely related to the tenured generation is the permanent generation which holds data needed by the virtual machine to describe objects that do not have an equivalence at the Java language level. For example objects describing classes and methods are stored in the permanent generation. From Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning 19

20 GC: Performance Considerations Measures of garbage collection performance: Throughput is the percentage of total time NOT spent in garbage collection, considered over long periods of time. Throughput includes time spent in allocation (but tuning for speed of allocation is generally not needed). Since collections occur when generations fill up, throughput is inversely proportional to the amount of memory available. Pauses are the times when an application appears unresponsive because garbage collection is occurring. Footprint is the working set of a process, measured in pages and cache lines. On systems with limited physical memory or many processes, footprint may dictate scalability. Promptness is the time between when an object becomes dead and when the memory becomes available, an important consideration for distributed systems, including remote method invocation (RMI). Remarks: Total available memory is the most important factor affecting garbage collection performance. Users have different requirements of garbage collection. For example, some consider the right metric for a web server to be throughput, since pauses during garbage collection may be tolerable, or simply obscured by network latencies. However, in an interactive graphics program even short pauses may negatively affect the user experience. In general, a particular generation sizing chooses a trade-off between these considerations. For example, a very large young generation may maximize throughput, but does so at the expense of footprint, promptness and pause times. Young generation pauses can be minimized by using a small young generation at the expense of throughput. The best choice is determined by the way the application uses memory as well as user requirements. Thus the virtual machine's choice of a garbage collector is not always optimal and may be overridden with command line options described below. 20

21 GC: Performance Measurement -verbose:gc [GC K->83000K(776768K), secs] [GC K->83372K(776768K), secs] [Full GC K->83769K(776768K), secs] -XX:+PrintGCDetails [GC [DefNew: 64575K->959K(64576K), secs] K->133633K(261184K), secs] -XX:+PrintGCTimeStamps : [GC : [DefNew: 8128K->8128K(8128K), secs] : [Tenured: 18154K->2311K(24576K), secs] 26282K->2311K(32704K), secs] -XX:+PrintTenuringDistribution [GC Desired survivor size bytes, new threshold 7 (max 15) 3869K->2628K(124928K), secs] [Full GC 2628K->2564K(124928K), secs] -Xloggc:<filename> -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime 21

22 GC: Tuning Options -Xms, -Xmx The size of the space reserved can be specified with the Xms and -Xmx options. If the value of the -Xms parameter is smaller than the value of the -Xmx parameter, not all of the space that is reserved is immediately committed to the virtual machine. -XX:MinHeapFreeRatio, XX:MaxHeapFreeRatio By default, the virtual machine grows or shrinks the heap at each collection to try to keep the proportion of free space to live objects at each collection within a specific range. This target range is set as a percentage by these parameters. -XX:NewSize, -XX:MaxNewSize The bigger the young generation, the less often minor collections occur. Bound the young generation size from below and above. Setting these to the same value fixes the young generation. -XX:NewRatio Ratio between the young and tenured generation of the total heap size. -XX:SurvivorRatio Sets the ratio between eden and a survivor space. 22

23 GC: Server Tuning Hints Decide the maximum heap size you can afford to give the virtual machine. Then plot your performance metric against young generation sizes to find the best setting. Note that the maximum heap size should always be smaller than the amount of memory installed on the machine, to avoid excessive page faults and thrashing. If the total heap size is fixed, increasing the young generation size requires reducing the tenured generation size. Keep the tenured generation large enough to hold all the live data used by the application at any given time, plus some amount of free space (10-20% or more). Increase the young generation size as you increase the number of processors, since allocation can be parallelized. 23

24 GC: Types Serial GC (-XX:+UseSerialGC) The serial collector uses a single thread to perform all garbage collection work, which makes it relatively efficient since there is no communication overhead between threads. Parallel GC (-XX:+UseParallelGC) The parallel collector (also known as the throughput collector) performs minor collections in parallel, which can significantly reduce garbage collection overhead. Since J2SE 5.0 update 6 the major collections can be done in parallel by enabling option -XX:+UseParallelOldGC. Concurrent GC (-XX:+UseConcMarkSweepGC) The concurrent collector performs most of its work concurrently (while the application is still running) to keep garbage collection pauses short. Garbage First GC (-XX:+UseG1GC) Since JDK 7 update 4. The heap is partitioned into a set of equal-sized heap regions, each a contiguous range of virtual memory. G1 performs a concurrent global marking phase to determine the liveness of objects throughout the heap. After the mark phase completes, G1 knows which regions are mostly empty. It collects in these regions first, which usually yields a large amount of free space. G1 concentrates its collection and compaction activity on the areas of the heap that are likely to be full of reclaimable objects, that is, garbage. 24

25 GC: Recommendations First run your application and allow the VM to select a collector. If necessary, adjust the heap size to improve performance. If the performance still does not meet your goals, then use the following guidelines as a starting point for selecting a collector. XX:+UseSerialGC If the application has a small data set (up to approximately 100MB). If the application will be run on a single processor and there are no pause time requirements, then let the VM select the collector or use serial GC. -XX:+UseParallelGC If (a) peak application performance is the first priority and (b) there are no pause time requirements or pauses of one second or longer are acceptable, then let the VM select the collector, or select the parallel collector and (optionally) enable parallel compaction with - XX:+UseParallelOldGC. -XX:+UseConcMarkSweepGC If response time is more important than overall throughput and garbage collection pauses must be kept shorter than approximately one second. -XX:+UseG1GC If more than 50% of the Java heap is occupied with live data and the rate of object allocation rate or promotion varies significantly and undesired long garbage collection or compaction pauses (longer than 0.5 to 1 second). 25

26 HotSpot: JIT Compilers JIT = Just-In-Time compilation Compiled when needed Immediately before execution or when it s important or never? Mixed-Mode Interpreted Bytecode-walking Artificial stack machine Compiled Direct native operations Native register machine Profiling Gather data about code while interpreting Invariants (types, constants, nulls) Statistics (branches, calls) Use that information to optimize Educated guess (can be wrong though) HotSpot VM -client mode (C1) inline less aggressive fewer opportunities to optimize -server mode (C2) inline aggressively based on richer runtime profiling Tiered Combines C1 and C2 -XX:+TieredCompilation 26

27 JIT: Optimizations The Golden Rule of Optimization Don t do unnecessary work! Optimistic Optimization Deoptimization Bail out of running code Monitoring flags uncommon trap we were wrong not entrant no new calls are allowed zombie to be dead Profile to find hot spots (HotSpot) Call sites Branch statistics Profile until 10K Inline mono/bimorphic calls Other methods for polymorphic calls Methods: Method inlining Combine caller and callee into one unit (e.g. based on profile) Perhaps with a guard/test Optimize as a whole More code means better visibility Loop unrolling Works for small, constant loops Avoid tests, branching Allow inlining a single call as many Lock coarsening/eliding Dead code elimination Duplicate code elimination Escape analysis All paths must inline No external view of object JRockit was better? (fix Hotspot!) 27

28 JIT Optimization: Inlining Source code: int addall(int max) { int accum = 0; for (int i = 0; i < max; i++) { accum = add(accum, i); return accum; int add(int a, int b) { return a + b; Optimized: int addall(int max) { int accum = 0; for (int i = 0; i < max; i++) { accum = accum + i; return accum; 28

29 JIT Optimization: Loop Unrolling Source Code: private static final String[] options = { "yes", "no", "maybe"; public void looper() { for (String option : options) { process(option); Optimized: private static final String[] options = { "yes", "no", "maybe"; public void looper() { process(options[0]); process(options[1]); process(options[2]); 29

30 JIT Optimization: Lock Coarsening Source Code: public void needslocks() { for (option : options) { process(option); private synchronized String process(string option) { // some wacky thread-unsafe code Optimized: public void needslocks() { synchronized (this) { for (option : options) { // some wacky thread-unsafe code 30

31 JIT Optimization: Lock Eliding Source Code: public void overcautious() { List l = new ArrayList(); synchronized (l) { for (option : options) { l.add(process(option)); Optimized: public void overcautious() { List l = new ArrayList(); for (option : options) { l.add( /* process() s code */); 31

32 JIT Optimization: Escape Analysis Source Code: private static class Foo { public final String a; public final String b; Foo(String a, String b) { this.a = a; this.b = b; Optimized: public secret BarBazQuux() { System.out.print("Hello"); System.out.print(", "); System.out.print( JVM"); System.out.println(!); public void bar() { Foo f = new Foo("Hello", "JVM"); baz(f); public void baz(foo f) { System.out.print(f.a); System.out.print(", "); quux(f); public void quux(foo f) { System.out.print(f.b); System.out.println(!); 32

33 JNI Java Native Interface (JNI) is a standard programming interface for writing Java native methods and embedding the JVM into native applications. Simply, it is a Java technology with which a Java application can call a method written with such as C, C++ and assembly. While you can write applications entirely in Java, there are situations where Java alone does not meet the needs of your application. Programmers use the JNI to write Java native methods to handle those situations when an application cannot be written entirely in Java. The following examples illustrate when you need to use Java native methods: The standard Java class library does not support the platform-dependent features needed by the application. You already have a library written in another language, and wish to make it accessible to Java code through the JNI. You want to implement a small portion of time-critical code in a lower-level language such as assembly. By programming through the JNI, you can use native methods to: Create, inspect, and update Java objects (including arrays and strings). Call Java methods. Catch and throw exceptions. Load classes and obtain class information. Perform runtime type checking. You can also use the JNI with the Invocation API to enable an arbitrary native application to embed the Java VM. This allows programmers to easily make their existing applications Javaenabled without having to link with the VM source code. javah tool that generates C header and source files that are needed to implement native methods. The generated header and source files are used by C programs to reference an object's instance variables from native source code. The.h file contains a struct definition whose layout parallels the layout of the corresponding class. The fields in the struct correspond to instance variables in the class. 33

34 JNI: Example Write Java class: package lt.vu.mif.javatech.uzd03; public class JniExample { public native String gethello(); static { System.loadLibrary("JniExample"); public void print () { String str = gethello(); System.out.println(str); public static void main(string[] args) { (new JniExample()).print(); Compile and create JNI stubs javac JniExample.java javah -jni JniExample Implement native function: #include "JniExample.h" JNIEXPORT jstring JNICALL Java_JniExample_getHello (JNIEnv \*env, jobject obj) { char* newstring; jstring ret = 0; newstring = "foo: Test program of JNI.\n"; ret = (\*env)->newstringutf(env, newstring); return ret; Compile native library: gcc -shared -fpic -o libjniexample.so - I/usr/java/include -I/usr/java/include/linux JniExample.c Execute Java application: java -Djava.library.path=<path_of_native_lib> JniExample 34

35 JNI: Invocation API The Invocation API allows software vendors to load the Java VM into an arbitrary native application. Vendors can deliver Java-enabled applications without having to link with the Java VM source code. I.e.: #include <jni.h> /* where everything is defined */... JavaVM *jvm; /* denotes a Java VM */ JNIEnv *env; /* pointer to native method interface */ JavaVMInitArgs vm_args; /* JDK/JRE 6 VM initialization arguments */ JavaVMOption* options = new JavaVMOption[1]; options[0].optionstring = "-Djava.class.path=/usr/lib/java"; vm_args.version = JNI_VERSION_1_6; vm_args.noptions = 1; vm_args.options = options; vm_args.ignoreunrecognized = false; /* load and initialize a Java VM, return a JNI interface pointer in env */ JNI_CreateJavaVM(&jvm, &env, &vm_args); delete options; /* invoke the Main.test method using the JNI */ jclass cls = env->findclass("main"); jmethodid mid = env->getstaticmethodid(cls, "test", "(I)V"); env->callstaticvoidmethod(cls, mid, 100); /* We are done. */ jvm->destroyjavavm(); 35

36 Session Conclusions During the session you have got familiar with JVM Huge efforts have been made to make it as it is now Garbage Collection and JIT compilation should be clear to you More efforts are needed in order to get comfortable with numerous HotSpot options Tricky questions during the exam, i.e. about your program What GC does it use? What is the max size of PERMGEN while running? What is the size of PERMGEN now? How many % of time did GC take? How many would it take if you change it? Have JIT optimized your code during the run? Which part exactly? Can you change it to be optimal from the beginning? Disassemble your program and find the code for class X? 36