Jvm

®

Understanding and Tuning the Java Virtual Machine (JVM) for WebSphere

© 2006 IBM Corporation

What you should know after this talk ƒ You should understand at a high level how the Java Virtual Machine (JVM) operates underneath your application server and the differences between the JVM’s on platforms

ƒ You should understand what the IBM J9 JVM is and what new features it provides to the runtime as well as when to use those features.

ƒ You will understand how different garbage collection schemes work and how to use them to effect your applications response times ƒ You will have a knowledge and understanding of some critical JVM tuning parameters that effect the runtime performance of the JVM

ƒ Lastly you will get to know which debugging tools are available for the JVM as well as understand when and where to use them most effectively. 2

Overview ƒ JVM Basics ƒ Overview of IBM’s J9 JVM ƒ Memory Management / Garbage Collection ƒ Runtime Performance Tuning ƒ Debugging Tools

3

JVM Basics Highest Level Overview ƒ Java is a Write Once Run Anywhere (WORA) 3rd generation Object Oriented programming language that is executed on a virtual machine ƒ The Java Virtual Machine (JVM) runs applications written in Java after the Java code has been compiled to bytecode via the javac process. ƒ The JVM in conjunction with other components performs optimization on your compiled Java code to attempt to make it as fast as native code ƒ The JVM performs automatic memory management (Garbage Collection) to ensure that system wide memory leaks do not occur and to allow for easier development by allowing developers not to explicitly have to perform memory management. ƒ There are multiple implementations of the JVM which all “should” execute any application written for the Java specification level that JVM was developed for. 4

JVM Basics Which JVM do I have?

ƒ The different platforms that WebSphere Application Server runs on have different JVM implementations in some cases

ƒ The IBM J9 JVM is the runtime environment on the following Operating Systems or Platforms 9 AIX, Windows, Linux (x86), Linux (PPC), iSeries, zSeries ƒ The Sun JVM is the runtime environment on all platforms running the Solaris Operating System

ƒ The HP JVM (which is a very simple Sun JVM port) is the runtime environment on all platforms running the HP-UX Operating System

5

JVM Basics The Overall Java Application Stack ƒ JVM is built using OO design. Building Block components providing higher level function for simplified end user development and runtime ƒ JVM’s core runtimes are developed in C or C++ and execute a large majority of function in native code 9 Garbage collector, MMU, JIT, etc 9 IO subroutines, OS calls ƒ The J2SE/J2EE APIs all exist at the Java Code layer. 9 Makes data structures available 9 Gives users access to needed function 9 Allow black box interactions with system 6

Java application code

Uses 1 of many possible configurations

Java calls

Pluggable components that dynamically load into the virtual machine

JNI

J2SE Virtual machine

JVM Profiler Debugger Realtime Profiler JIT

Thread model

Class loader

JNI

Interpreter Exception handler

JCL natives

Garbage collector

Port Library (file IO, sockets, memory allocation, etc.)

Operating system 7

Native applications

OS-specific calls

Calls to C libraries

JVM Basics Class loader basics

ƒ Uses parent-delegation model to allow additional security as well as allow users to implement their own class loaders 9 Loads classes in a hierarchical manner by delegating to the current class loaders parent recursively ƒ What does the class loader do? 9 Loading – Obtaining of the byte code from the java class file 9 Verification – Validates that the code inside the class file does not attempt to perform any illegal operations in the JVM and that the class file is well formed and not corrupt 9 Preparation – Performs allocation and initialization of storage space for static class fields. Also creates method tables and object templates 9 Initialization – Executes the classes initialization method and initializes static fields if your java class has them

8

JVM Basics JIT Basics

ƒ The just-in-time compiler (JIT) is not really part of the JVM but is essential for a high performing Java application 9 Java is Write Once Run Anywhere thus it is interpreted by nature and without the JIT could not compete with native code applications

ƒ The JIT works by compiling byte code loaded from the class loader when it is access by an application. 9 Due to different platforms having different JITs there is no standard method for when a method is compiled. 9 As your code accesses methods the JIT determines how frequently specific methods are accessed and compiles those touched often quickly to optimize performance

9

Overview ƒ JVM Basics ƒ Overview of IBM’s J9 JVM ƒ Memory Management / Garbage Collection ƒ Runtime Performance Tuning ƒ Debugging Tools

10

Overview of IBM’s J9 JVM Background

ƒ IBM Toronto Laboratory has a long history (30+ years) of expertise in programming language compilation and optimization technologies. 9 C, C++, Fortran, XML Parser, HPJ (statically compiled Java) 9 Language independent, interprocedural optimizers 9 Parallelization technology 9 Low-level compiler backends: optimizers, linkers, and code generators 9 Dynamic compilation: Java just-in-time (JIT) compilers ƒ Close relationships with: 9 Research : productizing innovative ideas and experimental technologies. 9 Hardware : understanding how to achieve the best possible performance with the underlying system and processor. 9 IBM Middleware : performance analysis ƒ Deep IP portfolio 9 Java JIT group alone filed 14 U.S. patents in 2004, 6 in 2005.

11

Overview of IBM’s J9 JVM What is the J9 JVM? ƒ Sun IP-free, but Java 2 (1.3) compliant (J2ME) and J2SE (1.4.2, 5.0) ƒ Highly configurable class library implementation ƒ Multi-platform 9 PowerPC, IA32, x86-64, and 390 (Linux or z/OS) 9 More applications than the above outside of the middleware space ƒ Flexible and sophisticated technology oriented to: 9 Performance (throughput and application startup) 9 Scalability 9 Reliability and Servicability (RAS)

12

Overview of IBM’s J9 JVM Scalability ƒ Garbage collector enhancements 9 Incorporates for the first time generational garbage collection ƒ Fine-grained locking of VM data structures ƒ Asynchronous compilation 9 Compilation of Java methods proceeds on a background thread • Other application threads do not have to wait to execute the method 9 Improves startup time of heavily multithreaded applications on SMPs ƒ Compile-time optimizations to remove contention 9 escape analysis, lock coarsening, … 9 architectural support to limit its effect ƒ Superior JIT (Just in time) compiler 9 Multiple optimization methods from application profiling to more intelligent and better code optimization algorithms

13

Overview of IBM’s J9 JVM Key Highlights for WAS

ƒ Superior Java application execution performance 9 Just-In-Time (JIT) compiler technology • Far improved over JDK 1.4.2 and Sun’s JIT • Maximized performance with minimized runtime overhead – multiple optimization levels, multiple recompilations of the same method, many new optimizations – dynamic observation of the execution of code via profiling to aggressively improve hot code – Interpreter profiling to adapt compilation to compiled methods for block reordering, loop unrolling, etc.

14

Overview ƒ JVM Basics ƒ Overview of IBM’s J9 JVM ƒ Memory Management / Garbage Collection ƒ Runtime Performance Tuning ƒ Debugging Tools

15

Memory Management / Garbage Collection Overview ƒ Garbage Collection (GC) - the main cause of memory–related performance bottlenecks in Java. ƒ Two things to look at in GC: frequency and duration 9 Frequency depends on the heap size and allocation rate 9 Duration depends on the heap size and Java heap footprint ƒ GC algorithm – it is critical to understand how it works so that tuning is done more intelligently. ƒ How do you eliminate GC bottlenecks 9 minimize the use of objects by following good programming practices 9 Set your heap size properly, memory-tune your JVM

16

Memory Management / Garbage Collection JVM Memory Layout

Application classes and objects JVM JVM Native Native Heap Heap

WAS Classes and Objects JVM Runtime classes, extension classes and objects

JVM Stack JVM Data Segment Segment JVM Native Code

JVM Data Segment

interpreter, verifier, JIT compiler, memory manager, etc

JVM OS Interface Operating System Operating System Typical JVM Architecture 17

Java Heap

Memory Management / Garbage Collection Total Application Memory Footprint Application classes and objects Application Resources, etc.

• Fixed Cost - WebSpere Runtime - XML Parser - ORB, JCE Security - JMX - Classloaders, etc • User-Controlled - Thread pool - Connection pool - Monitoring/Logging - EJB cache (growable?) - Other cache (prepared statement, security, etc )

Application Footprint

WAS Footprint

• Application Dependent - number of classes - dynacache - security - resources - HTTP session size - WLM 18

JVM Footprint

Native Implementation (e.g. C++) Data Structures, Code, Runtime artifacts, OS Interface

Memory Management / Garbage Collection What factors effect memory performance the most

ƒ Memory management – how efficient does the system manage memory ? ƒ Total available memory – is there enough memory to satisfy every request for memory ? ƒ Allocation Rate – how often does the application requests for memory ? ƒ Object Size – how big are these objects ? ƒ Object Lifetime – how long do these objects stay reserved by the application ?

19

Memory Management / Garbage Collection Parallel VS Concurrent Collectors

ƒ Parallel Collectors – two or more threads run at the same time to perform garbage collection 9Still uses the “stop-the-world” model but instead of only one GC thread, there are helper threads as well. ƒ Concurrent Collectors – collector threads are triggered to run while applications are running 9Does not use “Stop-the-world” but threads can be asked to perform garbage collection once in a while

20

Memory Management / Garbage Collection What garbage collection algorithms are available on my JDK? ƒ

IBM J9 JDK Platforms 9 Memory management is configurable using four different policies with varying characteristics 1. 2. 3. 4.

ƒ

Sun/HP JDK 5.0 Platforms 9 Garbage collector always Generational but implementation is chosen based on class of system out of the box 1. 2. 3.

21

Optimize for Throughput – flat heap collector focused on maximum throughput Optimize for Pause Time – flat heap collector with concurrent mark and sweep to minimize GC pause time Subpool – a flat heap technique to help increase performance on multiprocessor systems , commonly greater than 8. Available on IBM pSeries™ and zSeries™ Generational Concurrent – divides heap into “nursery” and “tenured” segments providing fast collection for short lived objects. Can provide maximum throughput with minimal pause times

Serial – Collects objects one at a time in both new and old generations Throughput - Uses a parallel model for collecting objects in the new generation Concurrent – Uses parallel collection in the new generation and concurrent in old.

Memory Management / Garbage Collection How the IBM Mark and Sweep Garbage Collector Works

Wilderness Thread B Used HeapHeap Thread Local

Stack

Garbage Used Heap Collector Global Heap Heap lock

Used Heap

Thread A Thread Local Heap

Stack

System Heap (JDK 1.4.2)

22

Thread Local Heap

Memory Management / Garbage Collection How the IBM J9 Generational and Sun/HP Garbage Collectors Work

JVM Heap Nursery/Young Generation

IBM J9: -Xmn (-Xmns/-Xmnx) Sun: -XX:NewSize=nn -XX:MaxNewSize=nn -Xmn<size>

Old Generation

IBM J9: -Xmo (-Xmos/-Xmox) Sun: -XX:NewRatio=n

Permanent Space

Sun JVM Only: -XX:MaxPermSize=nn

• Minor Collection – takes place only in the young generation, normally done through direct copying Æ very efficient • Major Collection – takes place in the old generation and uses the normal mark and sweep algorithm 23

Memory Management / Garbage Collection Fragmentation

ƒ Java Objects in the heap are in most cases moveable 9 In other words they are not tied to a single space in memory ƒ Some objects in the heap however cannot be moved either permanently or temporarily 9 Known as “pinned objects” ƒ What does J9 do to prevent fragmentation 9 With the addition of new garbage collection strategies as well as a new runtime memory management unit, pinned objects can be moved during compaction and accounted for in a much better manner with JDK 5.0 thus nearly eliminating the fragmentation problem seen in JDK 1.4.2 for the most part.

24

Overview ƒ JVM Basics ƒ Overview of IBM’s J9 JVM ƒ Memory Management / Garbage Collection ƒ Runtime Performance Tuning ƒ Debugging Tools

25

Runtime Performance Tuning Overview

ƒ Tuning the JVM properly is a process that takes time and must be tailored to your application. 9 HOWEVER you can typically get 80% of the maximum performance with 20% of the work by ensuring that you are making good choice on a few key settings 9 To truly extract maximum performance from your application you must know your applications memory allocation and runtime needs ƒ The JVM must be tuned in two iterative steps over a testing cycle 9 Step 1: Heap Size tuning 9 Step 2: Applying runtime optimization 9 Applying these two steps repeatedly will lead you to a JVM tuned for your application

26

Runtime Performance Tuning Key Parameters ƒ The key setting for the IBM JVM that effects performance most on all Java application and should get you near 80% of your maximum performance if set correctly is: 9 Heap Size (-Xms / -Xmx) 9 Ensure that you are setting your minimum and maximum to values that are under you physical memory limitation but allow you to have a substantially large interval between GC’s • Typical low end bound on frequency of GC’s is 10sec • Typical high end bound on duration of GC’s is 1-2sec ƒ For the Sun/HP JVM a lot more work is required to get optimal performance than just tuning the heap size as you need to tune the garbage collector and runtime as well 9 A new JVM setting was introduced in JDK 1.4.1 that for Sun has shown promise in automatically tuning the rest of heap settings for your machine • -XX:+AggresiveHeap is issued at the command line and it makes decisions on GC algorithms, Young/Old Generation spaces, and other resources to use. 9 One must also issue the –server parameter to the Sun/HP JVMs to get them to run in their highest performing mode. 27

Runtime Performance Tuning What GC Policy should I choose for the J9 JVM?

ƒ I want my application to run to completion as quickly as possible. 9 -Xgcpolicy:optthruput ƒ My application requires good response time to unpredictable events. 9 -Xgcpolicy:optavgpause ƒ My application has a high allocation and death rate. 9 -Xgcpolicy:gencon ƒ My application is running on big metal and has high allocation rates on many threads. 9 -Xgcpolicy:subpool

28

Runtime Performance Tuning Real world examples WebSphere 6.1 - Trade 6

ƒ Some WebSphere applications perform better with Generational – however some applications degrade in performance.

120 100 80 60 40 20 0 optthruput

ƒ Customer may still be interested in generational if it delivers lower GC pause times.

gencon

WebSphere 6.1 - SPECjAppServer 120 100 80 60 40 20 0 optthruput

gencon

Numbers are approximate and only intended to show a general behaviour seen when running Trade6 compared to SPECjAppServer 29

Runtime Performance Tuning Other IBM JVM Tuning Parameters ƒ -Xgcthreads

(default is n-1 for n processors)

ƒ -Xnoclassgc

- turns off class garbage collection (default is false)

ƒ -Xnocompactgc

- turns off compaction which can lead to fragmentation (default is false)

ƒ -Xoss<size>

- set the max Java stack size of any thread

ƒ -Xss<size>

- set the max native stack size of any thread

ƒ -Xlp

- enables large page support on supported Operating Systems

ƒ -Xdisableexplicitgc - turns System.gc() calls into no-ops ƒ -Xifa: - enables the Java code to run on z/OS zAAP processors ƒ -Xmaxe / -Xmine

30

- sets the maxium or minimum expansion unit during allocation

Runtime Performance Tuning What GC Policy should I choose for the Sun JVM?

ƒ I want my application to concurrently with a lot of other JVM’s (hoteling). 9 Use default serial collector as the GC algorithm is single threaded ƒ I need my application to perform good on a large number of processors. 9 -XX:+UseParallelGC ƒ I need my application to return near constant response times on machines that have a large number of processors. 9 -XX:+UseConcMarkSweepGC ƒ I need my application to return near constant response times on machines that have a small number of processors. 9 -XX:+UseTrainGC

31

Runtime Performance Tuning Other Sun/HP JVM Tuning Parameters

32

ƒ

-Xincgc

- incremental GC, uses the Train algorithm (default is disabled)

ƒ

-Xnoclassgc

- disable class garbage collection

ƒ

-Xss

- set the stack size of each thread (512K)

ƒ

-XX:+DisableExplicitGC - no System.gc() will be executed

ƒ

-XX:TargetSurvivorRatio - sets threshold in survivor space for promotion to kick in

ƒ

-XX:+UseAdaptiveSizePolicy - JVM determines good size for Eden, Survivor Spaces

ƒ

-XX:+UseISM

ƒ

-XX:+UseMPSS (used only for Solaris 9)

ƒ

-XX:+AggressiveHeap -maximizes heap size and algorithms for speed

ƒ

-Xoptgc

- allows for bigger pages (4MB)

- optimizes GC in Young Generation (HP only)

Runtime Performance Tuning How to tune a generation GC setup – General

ƒ We need to consider the respective size of the nursery and the tenured space. ƒ Two approaches 9 Dynamic • Specify the mininum and maxiumum heap size (e.g. –Xms512m – Xmx1024m) and in the Sun JDK case -XX:+AggressiveHeap • The JVM will dynamically size the nursery and tenured space. • May not give optimal performance • Could be good for low response times. 9 Fixed • Be more specific on the nursery and/or tenured space sizes. • Recommended approach for performance sensitive, server-side applications.

33

Runtime Performance Tuning How to tune a generation GC setup – Setting the tenured/old space

ƒ The tenured space must be large enough to hold all persistent data of the application. Too small will cause excessive GC or even out of memory conditions. ƒ For a typical WebSphere Application Server application this is ~100400Mb. ƒ One way to determine the tenure space size is to look at the amount of free heap exists after each GC in default mode 9 %free heap x Total heap size ƒ Analyse verbosegc to understand how frequently the tenured space gets collected. 9 An optimal generational application will never have a collection in the tenured space. 9 In the lab some WAS applications collect every ~15min. 34

Runtime Performance Tuning How to tune a generation GC setup – Setting the nursery/new generation space

ƒ Large nursery Æ “good for throughput” ƒ Small nursery Æ “good for low pause times” ƒ Good WebSphere performance (throughput) requires a reasonable large nursery. • A good starting point would be 512 megabyte. • Move up or down to determine optimal value. – Measure throughput and/or response times ƒ Analyse verbosegc to understand frequency and length of scavenges.

35

Tuning Heap size options ƒ Fix both nursery and tenured space -XmnAm

-XmoBm

Nursery 0

Tenured A

0

B

ƒ Allow them to expand/contract -XmnsAm -XmnxBm

A

36

-XmosBm -XmoxCm

B

C

Runtime Performance Tuning Process for tuning heap settings Set your Performance Requirements

Start

Adjust mx and/or ms and possibly switch GC policy

Give your best estimate for mx and ms

Stress test your application

No Profile objects If needed

GC profile is good?

Yes Done. 37

Analyze GC behavior

Tips Tips

Runyour yourapplication, application, ••Run analyzeheap heapusage usage analyze anddetermine determinethe the and steadystate. state. steady Setyour your ms ms to tothe the Set steadystate. state. steady Makesure sureyour yourheap heap ••Make neverpages. pages.Monitor Monitor never yourpaging pagingactivities. activities. your ruleof ofthumb thumbisisto to ••AArule keep30% 30%of ofyour your keep heapfree freemost mostof of heap thetime. time. the

Runtime Performance Tuning Process for other runtime tuning settings Set your Performance Requirements

Start

Set your baseline tuning parameters

Stress test your application

Apply new Tuning parameter To runtime

No Remove tuning Parameter if Negative effect

Is throughput as expected?

Yes Done. 38

Analyze Runtime behavior

Tips Tips

Measurethroughput throughput ••Measure duringsteady steadystate stateof of during thebenchmark benchmarkto to the ensureconsistent consistent ensure results results Sometuning tuning ••Some

parameterswill willeffect effect parameters performancenegatively negatively performance asthey theymight mightbe be as targetedfor foran an targeted applicationwith withdifferent different application runtimecharacteristics characteristics runtime thanyour yourapplication application than Addonly onlyone onetuning tuning •• Add parameterat ataatime timeto to parameter measureits itsimpact impactalone alone measure

Overview ƒ JVM Basics ƒ Overview of IBM’s J9 JVM ƒ Memory Management / Garbage Collection ƒ Runtime Performance Tuning ƒ Debugging Tools

39

Debugging Tools Garbage Collection Debugging/Analysis Tools (Verbose:GC)

Your most indispensable tool Æ directly from the JVM runtime

Enabled by issuing –verbose:gc on the java command line

Pros 9 can give a lot of detailed low-level information for serious debugging, enough for initial investigation 9 readily available and it is free Cons 9 Have to restart your server Æ not suitable for production environments 9 does not give object-level information for further analysis

40

Runtime Performance Tuning Verbose:GC from J9 <minimum requested_bytes="144" /> <soa freebytes="58201944" totalbytes="199229440" percent="29" />

Allocation request details, time it took to stop all mutator threads.



Heap occupancy details before GC.

<scavenger tiltratio="90" />

Details about the scavenge.

<soa freebytes="57022296" totalbytes="199229440" percent="28" /> <soa freebytes="57022296" totalbytes="199229440" percent="28" />

41

Heap occupancy details after GC.

Debugging Tools Garbage Collection Debugging/Analysis Tools – Sun/HP JVM verbose:gc output

-verbose:gc –XX:+PrintTenuringDistribution –XX:+PrintGCDetails –XX:+PrintGCStamps ƒ

Example:

ƒ

0.0000013: [Full GC 0.0005366: [Tenured: 0K->4185K(1380352K), 0.3102502 secs] 62984K->4185K(2057344K), 0.3103787 secs]

ƒ

236.661: [GC 236.661: [DefNew

ƒ

Desired survivor size 61145088 bytes, new threshold 31 (max 31)

ƒ

- age 1: 16817808 bytes, 16817808 total

ƒ

- age 2: 20124840 bytes, 36942648 total

ƒ

: 630283K->36076K(657088K), 0.7287377 secs] 666617K->72411K(2037440K), 0.7289491 secs]

ƒ

42

262.697: [GC 262.697: [DefNew

ƒ

Desired survivor size 61145088 bytes, new threshold 31 (max 31)

ƒ

- age 1: 15971824 bytes, 15971824 total

ƒ

- age 2:

ƒ

- age 3: 18963992 bytes, 38742008 total

ƒ

: 633452K->37833K(657088K), 0.6451270 secs] 669787K->74168K(2037440K), 0.6453326 secs]

3806192 bytes, 19778016 total

ƒ

286.232: [GC 286.233: [DefNew

ƒ

Desired survivor size 61145088 bytes, new threshold 31 (max 31)

ƒ

- age 1: 17242304 bytes, 17242304 total

ƒ

- age 2:

5131296 bytes, 22373600 total

ƒ

- age 3:

2684464 bytes, 25058064 total

ƒ

- age 4: 18728192 bytes, 43786256 total

ƒ

: 635209K->42760K(657088K), 0.7164103 secs] 671544K->79094K(2037440K), 0.7166029 secs]

Debugging Tools IBM JDK Debugging/Analysis Tools ƒ Thread dumps 9 Available on all JVM’s by issuing kill -3 on the command line where the is your servers process id 9 In essence a snap shot in time of what your system is executing. Used to debug and find where threads are spending time in your system, or are hung in your system ƒ Heap dump 9 Can be enabled to occur with a thread dump by setting the following JVM properties • Click on Application Server -> server1 -> Process definition -> custom properties -> • Enter Name = IBM_HEAPDUMP • Value = true • Enter Name = IBM_JAVA_HEAPDUMP_TEXT (this enables generating heapdump in txt format, which can be analyzed using heaproots) • Value = true 9 Can be analyzed using HeapRoots at http://www.alphaworks.ibm.com/tech/heaproots 43

Debugging Tools IBM JDK Debugging/Analysis Tools

ƒ Class loader runtime diagnostics 9 -verbose:class – Gives you information about which classes are loaded 9 -Dibm.cl.verbose= - Gives you specific information about how a class name you define is attempted to me loaded. ƒ Runtime Performance Analysis 9 A variety of third party tools will hook up to the IBM JVM to provide runtime level profiling • Jprobe, Jprofiler, etc 9 Hprof if built into the JDK as a profiler but is limited in function however still good for debugging simple unit test case performance issues.

44

A few VERY useful URLs

ƒ http://www-106.ibm.com/developerworks/java/jdk/diagnosis/ 9 Contains all the diagnostic guides for our JVMs 9 PDF on GC and Memory usage ƒ http://java.sun.com/docs/performance 9 Contains a large amount of documentation and tuning for the Sun JVM 9 Reference to all SUN JVM flags as well as an explanation of them ƒ http://www.hp.com/products1/unix/java/infolibrary/index.html 9 Wealth of information on tuning and configuring the HPUX JVM

45

Thank you Any questions ?

46

Backup and Extras

47

JVM Basics The high level JVM Building Blocks – Part 1

IBM JVM

ƒ Core Interface – Encapsulates all interactions with user, external programs and operating environment

Core Interface (CI) Execution Management (XM) Execution Engine (XE)

ƒ Execution Management – Provides process control and management 9 Threading engine resides here

48

ƒ Execution Engine - – Provides all methods of executing Java Byte Code both compiled and interpreted.

JVM Basics The high level JVM Building Blocks – Part 2

IBM JVM

ƒ Diagnostics – Encapsulates all debug and diagnostic services in the JVM

Execution Management (XM)

9 Tracing, FFDC, RAS, Debug APIs

Execution Engine (XE)

Core Interface (CI)

Diagnostics (DG)

ƒ Class Loader – Provides support for loading and unloading of Java binaries 9 Performs loading, validation, initialization, and implements methods for reflection APIs 49

ƒ Data Conversion – Supports

Data Conversion

Class Loader (CL)

JVM Basics The high level JVM Building Blocks – Part 3

IBM JVM

ƒ Lock – Provides locking and synchronization services

Core Interface (CI) Execution Management (XM)

ƒ Storage – Encompasses all support for storage services the JVM needs 9 Heap management, and allocation strategies

Execution Engine (XE) Diagnostics (DG)

Class Loader (CL)

Data Conversion

Lock (LK)

Storage (ST)

50

ƒ HPI – A set of well defined functions that provide low level facilities and services in a platform neutral way. 9 This interface is defined by

HPI

Memory Management / Garbage Collection How the Sun/HP Garbage Collector Works – Part 2 -XX:SurvivorRatio=nn

Eden

Young Generation

51

-XX:MaxTenuringThreshold=nn

Survivor Space

Old Generation

Survivor Space

Permanent Space