Java Technologies. JAVA basics - uosis.mif.vu.ltuosis.mif.vu.lt/~valdo/jate2015/JavaTech.L08.pdf ·...

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-02-070, funded by The European Social Fund Agency and the Government of Lithuania.

Valdas Rapševičius Vilnius University

Faculty of Mathematics and Informatics

2015.05.25

Java Technologies Lecture IV

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 in-depth 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 2015.05.25 Valdas Rapševičius. Java Technologies

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…


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

2015.05.25 Valdas Rapševičius. Java Technologies 4

Java code to JVM

2015.05.25 Valdas Rapševičius. Java Technologies 5

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


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


JVM: Example (2)

~ $ xxd ManoKlase.class 0000000: cafe babe 0000 0032 0028 0a00 0600 1407 .......2.(...... 0000010: 0015 0a00 0200 1409 0016 0017 0800 1807 ................ 0000020: 0019 0a00 0200 1a0a 001b 001c 0a00 1d00 ................ 0000030: 1e01 0006 3c69 6e69 743e 0100 0328 2956 ....<init>...()V 0000040: 0100 0443 6f64 6501 000f 4c69 6e65 4e75 ...Code...LineNu 0000050: 6d62 6572 5461 626c 6501 0004 7375 6d61 mberTable...suma 0000060: 0100 0528 4949 2949 0100 046d 6169 6e01 ...(II)I...main. 0000070: 0016 285b 4c6a 6176 612f 6c61 6e67 2f53 ..([Ljava/lang/S 0000080: 7472 696e 673b 2956 0100 0a53 6f75 7263 tring;)V...Sourc 0000090: 6546 696c 6501 000e 4d61 6e6f 4b6c 6173 eFile...ManoKlas 00000a0: 652e 6a61 7661 0c00 0a00 0b01 0009 4d61 e.java........Ma 00000b0: 6e6f 4b6c 6173 6507 001f 0c00 2000 2101 noKlase..... .!. 00000c0: 000b 5375 6d61 203d 2025 6425 6e01 0010 ..Suma = %d%n... 00000d0: 6a61 7661 2f6c 616e 672f 4f62 6a65 6374 java/lang/Object 00000e0: 0c00 0e00 0f07 0022 0c00 2300 2407 0025 ......."..#.$..% 00000f0: 0c00 2600 2701 0010 6a61 7661 2f6c 616e ..&.'...java/lan 0000100: 672f 5379 7374 656d 0100 036f 7574 0100 g/System...out.. 0000110: 154c 6a61 7661 2f69 6f2f 5072 696e 7453 .Ljava/io/PrintS 0000120: 7472 6561 6d3b 0100 116a 6176 612f 6c61 tream;...java/la 0000130: 6e67 2f49 6e74 6567 6572 0100 0776 616c ng/Integer...val 0000140: 7565 4f66 0100 1628 4929 4c6a 6176 612f ueOf...(I)Ljava/ 0000150: 6c61 6e67 2f49 6e74 6567 6572 3b01 0013 lang/Integer;... 0000160: 6a61 7661 2f69 6f2f 5072 696e 7453 7472 java/io/PrintStr …


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


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 }


Disassembling

• Check available options if PrintAssembler exists java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal –version

• Download hsdis library from http://kenai.com/projects/base-hsdis/downloads

• 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


http://kenai.com/projects/base-hsdis/downloads

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.


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


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.


HotSpot: Command Line Options (2)

• Check available options: java -XX:+AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal –version


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.


Garbage Collection

• “Heap storage for objects is reclaimed by an automatic storage management system (typically a garbage collector); objects are never explicitly de-allocated.” 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.

17

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

2015.05.25 Valdas Rapševičius. Java Technologies

From Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning

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


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

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.


GC: Performance Measurement

• -verbose:gc

[GC 325407K->83000K(776768K), 0.2300771 secs] [GC 325816K->83372K(776768K), 0.2454258 secs] [Full GC 267628K->83769K(776768K), 1.8479984 secs]

• -XX:+PrintGCDetails

[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]

• -XX:+PrintGCTimeStamps

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs] 111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

• -XX:+PrintTenuringDistribution

[GC Desired survivor size 5505024 bytes, new threshold 7 (max 15) 3869K->2628K(124928K), 0.0002030 secs] [Full GC 2628K->2564K(124928K), 0.0025833 secs]

• -Xloggc:<filename> • -XX:+PrintGCApplicationConcurrentTime • -XX:+PrintGCApplicationStoppedTime


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.


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.


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.


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


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


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


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


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


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


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


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

• Optimized:

public secret BarBazQuux() { System.out.print("Hello"); System.out.print(", "); System.out.print(“JVM"); System.out.println(!); }


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 Java-enabled 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.


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

34

• 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

2015.05.25 Valdas Rapševičius. Java Technologies

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


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?


Java Technologies. JAVA basics - uosis.mif.vu.ltuosis.mif.vu.lt/~valdo/jate2015/JavaTech.L08.pdf ·...

Documents

Transcript of Java Technologies. JAVA basics - uosis.mif.vu.ltuosis.mif.vu.lt/~valdo/jate2015/JavaTech.L08.pdf ·...