Systems i Advantages Perfmgmt Diag60

IBM Developer Kit and Runtime Environment, Java Technology Edition, Version 6

Diagnostics Guide

Version 6

NoteBefore using this information and the product it supports, read the information in Notices on page 491.

Sixth Edition (June 2009)

This edition applies to all the platforms that are included in the IBM Developer Kit and Runtime Environment, JavaTechnology Edition, Version 6 and to all subsequent releases and modifications until otherwise indicated in neweditions. Technical changes since the Version 5.0 edition made for the Version 6 edition of this book are indicated byvertical bars to the left of the changes.

Copyright International Business Machines Corporation 2003, 2009.US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

ContentsFigures . . . . . . . . . . . . . . . ix

Tables . . . . . . . . . . . . . . . xi

About the Diagnostics Guide . . . . . xiiiWhat does the Java Virtual Machine (JVM) mean? xiiiWho should read this book . . . . . . . . . xivUsing this book. . . . . . . . . . . . . xivOther sources of information . . . . . . . . xivReporting problems in the JVM . . . . . . . xvConventions and terminology . . . . . . . . xvHow to send your comments . . . . . . . . xvContributors . . . . . . . . . . . . . . xviSummary of changes . . . . . . . . . . . xvi

Part 1. Understanding the IBM SDKfor Java . . . . . . . . . . . . . . 1

Chapter 1. The building blocks of theIBM Virtual Machine for Java. . . . . . 3Java application stack . . . . . . . . . . . 4Components of the IBM Virtual Machine for Java . . 4

JVM API. . . . . . . . . . . . . . . 5Diagnostics component . . . . . . . . . . 5Memory management . . . . . . . . . . 5Class loader . . . . . . . . . . . . . 6Interpreter . . . . . . . . . . . . . . 6Platform port layer . . . . . . . . . . . 6

Chapter 2. Memory management . . . . 7Overview of memory management . . . . . . . 7

Object allocation . . . . . . . . . . . . 7Reachable objects . . . . . . . . . . . . 8Garbage collection . . . . . . . . . . . 8Heap sizing problems . . . . . . . . . . 8

Allocation . . . . . . . . . . . . . . . 9Heap lock allocation . . . . . . . . . . . 9Cache allocation . . . . . . . . . . . . 9Large Object Area . . . . . . . . . . . 10Compressed references . . . . . . . . . 11

Detailed description of garbage collection . . . . 12Mark phase . . . . . . . . . . . . . 12Sweep phase . . . . . . . . . . . . . 14Compaction phase . . . . . . . . . . . 16Subpool (AIX, Linux PPC and zSeries, z/OS andi5/OS only) . . . . . . . . . . . . . 16Reference objects . . . . . . . . . . . 17Final reference processing . . . . . . . . 18JNI weak reference . . . . . . . . . . . 18Heap expansion . . . . . . . . . . . . 18Heap shrinkage . . . . . . . . . . . . 19

Generational Concurrent Garbage Collector. . . . 20Tenure age. . . . . . . . . . . . . . 21

Tilt ratio . . . . . . . . . . . . . . 21Split heap . . . . . . . . . . . . . . 21

How to do heap sizing . . . . . . . . . . 22Initial and maximum heap sizes . . . . . . 22Using verbose:gc . . . . . . . . . . . 23Using fine tuning options. . . . . . . . . 23

Interaction of the Garbage Collector withapplications . . . . . . . . . . . . . . 24How to coexist with the Garbage Collector . . . . 24

Root set . . . . . . . . . . . . . . 24Thread local heap . . . . . . . . . . . 25Bug reports . . . . . . . . . . . . . 25Finalizers . . . . . . . . . . . . . . 25Manually starting the Garbage Collector. . . . 27

Frequently asked questions about the GarbageCollector . . . . . . . . . . . . . . . 27

Chapter 3. Class loading . . . . . . . 31The parent-delegation model . . . . . . . . 31Namespaces and the runtime package . . . . . 32Custom class loaders . . . . . . . . . . . 32

Chapter 4. Class data sharing . . . . . 35

Chapter 5. The JIT compiler. . . . . . 37JIT compiler overview . . . . . . . . . . . 37How the JIT compiler optimizes code. . . . . . 38

Phase 1 - inlining . . . . . . . . . . . 38Phase 2 - local optimizations . . . . . . . 38Phase 3 - control flow optimizations . . . . . 39Phase 4 - global optimizations . . . . . . . 39Phase 5 - native code generation . . . . . . 39

Frequently asked questions about the JIT compliler 39

Chapter 6. The AOT compiler . . . . . 41

Chapter 7. Java Remote MethodInvocation . . . . . . . . . . . . . 43The RMI implementation . . . . . . . . . . 43Thread pooling for RMI connection handlers . . . 44Understanding distributed garbage collection (DGC) 44Debugging applications involving RMI . . . . . 45

Chapter 8. The ORB . . . . . . . . . 47CORBA. . . . . . . . . . . . . . . . 47RMI and RMI-IIOP . . . . . . . . . . . . 47Java IDL or RMI-IIOP? . . . . . . . . . . 48RMI-IIOP limitations . . . . . . . . . . . 48Further reading . . . . . . . . . . . . . 48Examples of clientserver applications . . . . . 49

Interfaces . . . . . . . . . . . . . . 49Remote object implementation (or servant) . . . 49Stubs and ties generation . . . . . . . . . 50Server code . . . . . . . . . . . . . 50

Copyright IBM Corp. 2003, 2009 iii

Summary of major differences between RMI(JRMP) and RMI-IIOP . . . . . . . . . . 53

Using the ORB . . . . . . . . . . . . . 54How the ORB works . . . . . . . . . . . 58

The client side . . . . . . . . . . . . 58The server side . . . . . . . . . . . . 62

Additional features of the ORB . . . . . . . . 64Portable object adapter . . . . . . . . . 64Fragmentation . . . . . . . . . . . . 66Portable interceptors . . . . . . . . . . 66Interoperable Naming Service (INS) . . . . . 69

Chapter 9. The Java Native Interface(JNI) . . . . . . . . . . . . . . . . 71Overview of JNI . . . . . . . . . . . . . 71The JNI and the Garbage Collector . . . . . . 72

Overview of JNI object references . . . . . . 72JNI transitions . . . . . . . . . . . . 75

Copying and pinning . . . . . . . . . . . 76Using the isCopy flag . . . . . . . . . . 77Using the mode flag . . . . . . . . . . 77A generic way to use the isCopy and mode flags 78

Handling exceptions . . . . . . . . . . . 78Synchronization . . . . . . . . . . . . . 78Debugging the JNI . . . . . . . . . . . . 79JNI checklist . . . . . . . . . . . . . . 81

Part 2. Submitting problem reports 83

Chapter 10. Overview of problemsubmission . . . . . . . . . . . . . 85How does the IBM service team service Java? . . . 85Submitting Java problem reports to IBM service . . 85Problem severity ratings . . . . . . . . . . 86Escalating problem severity . . . . . . . . . 86Java duty manager . . . . . . . . . . . . 87

Chapter 11. MustGather: collecting thecorrect data to solve problems . . . . 89Before you submit a problem report . . . . . . 89Data to include . . . . . . . . . . . . . 89Test cases . . . . . . . . . . . . . . . 90Performance problems . . . . . . . . . . . 90

Factors that affect JVM performance . . . . . 91Questions to ask about performance problems . . 91

Chapter 12. Submitting data with aproblem report . . . . . . . . . . . 93Sending files to IBM service . . . . . . . . . 93Obtaining files from IBM service . . . . . . . 94Compressing files . . . . . . . . . . . . 95How you receive your fix . . . . . . . . . 95

Part 3. Problem determination . . . 97

Chapter 13. First steps in problemdetermination . . . . . . . . . . . . 99

Chapter 14. AIX problemdetermination . . . . . . . . . . . 101Setting up and checking your AIX environment 101

Enabling full AIX core files . . . . . . . . 102General debugging techniques. . . . . . . . 103

AIX debugging commands . . . . . . . . 104DBX Plug-in . . . . . . . . . . . . . 113

Diagnosing crashes . . . . . . . . . . . 114Documents to gather . . . . . . . . . . 114Locating the point of failure . . . . . . . 115

Debugging hangs . . . . . . . . . . . . 116AIX deadlocks . . . . . . . . . . . . 116AIX busy hangs . . . . . . . . . . . 116Poor performance on AIX . . . . . . . . 118

Understanding memory usage . . . . . . . . 11932- and 64-bit JVMs . . . . . . . . . . 119The 32-bit AIX Virtual Memory Model . . . . 119The 64-bit AIX Virtual Memory Model . . . . 120Changing the Memory Model (32-bit JVM) . . 121The native and Java heaps . . . . . . . . 121The AIX 32-bit JVM default memory models 122Monitoring the native heap. . . . . . . . 122Native heap usage. . . . . . . . . . . 123Specifying MALLOCTYPE . . . . . . . . 124Monitoring the Java heap . . . . . . . . 124Receiving OutOfMemoryError exceptions . . . 124Is the Java or native heap exhausted? . . . . 125Java heap exhaustion . . . . . . . . . . 125Native heap exhaustion . . . . . . . . . 125AIX fragmentation problems . . . . . . . 126Submitting a bug report . . . . . . . . . 127

Debugging performance problems . . . . . . 127Finding the bottleneck . . . . . . . . . 127CPU bottlenecks . . . . . . . . . . . 128Memory bottlenecks . . . . . . . . . . 132I/O bottlenecks. . . . . . . . . . . . 132JVM heap sizing . . . . . . . . . . . 133JIT compilation and performance . . . . . . 133Application profiling . . . . . . . . . . 133

MustGather information for AIX . . . . . . . 133

Chapter 15. Linux problemdetermination . . . . . . . . . . . 135Setting up and checking your Linux environment 135General debugging techniques. . . . . . . . 137

Using the dump extractor . . . . . . . . 137Using system dump tools . . . . . . . . 138Examining process information . . . . . . 138ldd . . . . . . . . . . . . . . . . 140Tracing tools . . . . . . . . . . . . 140Debugging with gdb . . . . . . . . . . 141

Diagnosing crashes . . . . . . . . . . . 143Debugging hangs . . . . . . . . . . . . 144Debugging memory leaks . . . . . . . . . 145Debugging performance problems . . . . . . 145

Finding the bottleneck . . . . . . . . . 145CPU usage . . . . . . . . . . . . . 146Memory usage . . . . . . . . . . . . 146Network problems . . . . . . . . . . 146JVM heap sizing . . . . . . . . . . . 147

iv IBM SDK for Java: Diagnostics Guide

JIT compilation and performance . . . . . . 147Application profiling . . . . . . . . . . 147

MustGather information for Linux . . . . . . 148Known limitations on Linux . . . . . . . . 150

Chapter 16. Windows problemdetermination . . . . . . . . . . . 153Setting up and checking your Windowsenvironment. . . . . . . . . . . . . . 153

Windows 32-bit large address aware support 154General debugging techniques. . . . . . . . 155

Using the Cross-Platform Dump Viewer . . . 155System dump . . . . . . . . . . . . 155

Diagnosing crashes in Windows . . . . . . . 156Collecting system dumps on Windows when-Xrs is set . . . . . . . . . . . . . 156Data to send to IBM . . . . . . . . . . 159

Debugging hangs . . . . . . . . . . . . 159Getting a dump from a hung JVM . . . . . 159Analyzing deadlocks . . . . . . . . . . 160

Debugging memory leaks . . . . . . . . . 160The Windows memory model . . . . . . . 160Classifying leaks . . . . . . . . . . . 161Tracing leaks . . . . . . . . . . . . 161Using Heapdump to debug memory leaks. . . 161

OutOfMemoryError creating a thread . . . . . 162Debugging performance problems . . . . . . 162

Finding the bottleneck . . . . . . . . . 162Windows systems resource usage. . . . . . 162JVM heap sizing . . . . . . . . . . . 163JIT compilation and performance . . . . . . 163Application profiling . . . . . . . . . . 163

MustGather information for Windows . . . . . 163

Chapter 17. z/OS problemdetermination . . . . . . . . . . . 165Setting up and checking your z/OS environment 165

Maintenance. . . . . . . . . . . . . 165LE settings . . . . . . . . . . . . . 165Environment variables . . . . . . . . . 165Private storage usage . . . . . . . . . . 165Setting up dumps . . . . . . . . . . . 166

General debugging techniques. . . . . . . . 167Using IPCS commands . . . . . . . . . 167Using dbx . . . . . . . . . . . . . 168Interpreting error message IDs . . . . . . 168

Diagnosing crashes . . . . . . . . . . . 169Documents to gather . . . . . . . . . . 169Determining the failing function . . . . . . 170Working with TDUMPs using IPCS . . . . . 172

Debugging hangs . . . . . . . . . . . . 176The process is deadlocked . . . . . . . . 176The process is looping . . . . . . . . . 176The process is performing badly . . . . . . 177

Understanding Memory Usage . . . . . . . 177Allocations to LE HEAP . . . . . . . . . 177z/OS virtual storage . . . . . . . . . . 178OutOfMemoryError exceptions . . . . . . 178

Debugging performance problems . . . . . . 179Finding the bottleneck . . . . . . . . . 180

z/OS systems resource usage . . . . . . . 180JVM heap sizing . . . . . . . . . . . 180JIT compilation and performance . . . . . . 180Application profiling . . . . . . . . . . 180

MustGather information for z/OS . . . . . . 181

Chapter 18. i5/OS problemdetermination . . . . . . . . . . . 183Determining which VM is in use . . . . . . . 183Setting up your IBM Technology for JavaEnvironment . . . . . . . . . . . . . 183

Required Software and Licensing . . . . . . 183Configuring JAVA_HOME . . . . . . . . 184Enabling i5/OS PASE core files . . . . . . 185Setting environment variables for i5/OS PASEor QShell . . . . . . . . . . . . . . 186Determining a users home directory . . . . 187Setting default Java command-line options . . 187

General debugging techniques. . . . . . . . 189Diagnosing problems at the command line . . . 189i5/OS debugging commands . . . . . . . . 189

Work with Active Jobs (WRKACTJOB) . . . . 190Work with Job (WRKJOB) . . . . . . . . 190Work with System Status (WRKSYSSTS) . . . 190Work with Disk Status (WRKDSKSTS) . . . . 190Process Status (ps). . . . . . . . . . . 190Debugger (dbx). . . . . . . . . . . . 191

Debugging performance problems . . . . . . 191Analyzing CPU bottlenecks. . . . . . . . 191Analyzing memory problems . . . . . . . 193Analyzing I/O problems . . . . . . . . 194

Diagnosing crashes . . . . . . . . . . . 198Checking the system environment . . . . . 198Finding out about the Java environment . . . 198Detailed crash diagnosis . . . . . . . . . 198

Diagnosing hangs . . . . . . . . . . . . 198i5/OS deadlocks . . . . . . . . . . . 198i5/OS busy hangs . . . . . . . . . . . 198

Understanding memory usage. . . . . . . . 199The 32-bit i5/OS PASE Virtual memory model 199The process and garbage-collected heaps . . . 200Monitoring the garbage-collected heap . . . . 200Process heap usage . . . . . . . . . . 200OutOfMemoryError exceptions . . . . . . 201Garbage-collected heap exhaustion . . . . . 201Submitting a bug report . . . . . . . . . 201

Using dbx . . . . . . . . . . . . . . 202Using the DBX Plug-in for Java . . . . . . 202Important dbx usage notes and warnings . . . 203Using dbx to investigate a Java system dump 203Starting dbx on a system dump(core.{date}.{time}.{pid}.dmp) . . . . . . . 204

Chapter 19. Sun Solaris problemdetermination . . . . . . . . . . . 205

Chapter 20. Hewlett-Packard SDKproblem determination . . . . . . . 207

Contents v

Chapter 21. ORB problemdetermination . . . . . . . . . . . 209Identifying an ORB problem . . . . . . . . 209Debug properties . . . . . . . . . . . . 210ORB exceptions. . . . . . . . . . . . . 211Completion status and minor codes . . . . . . 212Java security permissions for the ORB . . . . . 213Interpreting the stack trace . . . . . . . . . 214

Description string . . . . . . . . . . . 215Interpreting ORB traces . . . . . . . . . . 215

Message trace . . . . . . . . . . . . 215Comm traces . . . . . . . . . . . . 216Client or server. . . . . . . . . . . . 217Service contexts . . . . . . . . . . . 218

Common problems . . . . . . . . . . . 218ORB application hangs . . . . . . . . . 218Running the client without the server runningbefore the client is started . . . . . . . . 219Client and server are running, but not namingservice. . . . . . . . . . . . . . . 220Running the client with MACHINE2 (client)unplugged from the network . . . . . . . 220

IBM ORB service: collecting data . . . . . . . 221Preliminary tests . . . . . . . . . . . 221

Chapter 22. NLS problemdetermination . . . . . . . . . . . 223Overview of fonts . . . . . . . . . . . . 223Font utilities. . . . . . . . . . . . . . 224Common NLS problem and possible causes . . . 224

Part 4. Using diagnostic tools . . . 227

Chapter 23. Overview of the availablediagnostics . . . . . . . . . . . . 229Categorizing the problem . . . . . . . . . 229Summary of diagnostic information . . . . . . 229Summary of cross-platform tooling . . . . . . 231

Heapdump analysis tooling . . . . . . . 231Cross-platform dump viewer . . . . . . . 231JVMTI tools . . . . . . . . . . . . . 231JVMPI tools . . . . . . . . . . . . . 232JPDA tools . . . . . . . . . . . . . 232DTFJ . . . . . . . . . . . . . . . 232Trace formatting . . . . . . . . . . . 232JVMRI. . . . . . . . . . . . . . . 233

Scenarios in which dumps might not be produced 233Identifying if the race condition exists . . . . 234Obtaining system dumps in a race condition 235Stack overflow conditions in Windows . . . . 236Stack overflow conditions on Linux . . . . . 236System resource limits on AIX and Linux . . . 237Native memory exhaustion in Windows . . . 237

Chapter 24. Using dump agents . . . 239Using the -Xdump option . . . . . . . . . 239

Merging -Xdump agents. . . . . . . . . 241Dump agents . . . . . . . . . . . . . 243

Console dumps. . . . . . . . . . . . 243

System dumps . . . . . . . . . . . . 244Stack dumps . . . . . . . . . . . . 244LE CEEDUMPs. . . . . . . . . . . . 244Tool option . . . . . . . . . . . . . 245Javadumps . . . . . . . . . . . . . 246Heapdumps . . . . . . . . . . . . . 246Snap traces . . . . . . . . . . . . . 247

Dump events . . . . . . . . . . . . . 248Advanced control of dump agents . . . . . . 249

exec option . . . . . . . . . . . . . 249file option . . . . . . . . . . . . . 249filter option . . . . . . . . . . . . . 249opts option . . . . . . . . . . . . . 251Priority option . . . . . . . . . . . . 251range option. . . . . . . . . . . . . 252request option . . . . . . . . . . . . 252defaults option . . . . . . . . . . . . 252

Dump agent tokens . . . . . . . . . . . 253Default dump agents . . . . . . . . . . . 253Removing dump agents . . . . . . . . . . 254Dump agent environment variables . . . . . . 255Signal mappings . . . . . . . . . . . . 256Windows, Linux, AIX, and i5/OS specifics . . . 257z/OS specifics . . . . . . . . . . . . . 257Disabling dump agents with -Xrs. . . . . . . 259

Chapter 25. Using Javadump. . . . . 261Enabling a Javadump. . . . . . . . . . . 261Triggering a Javadump . . . . . . . . . . 261Interpreting a Javadump . . . . . . . . . 262

Javadump tags . . . . . . . . . . . . 263TITLE, GPINFO, and ENVINFO sections . . . 264Storage Management (MEMINFO) . . . . . 266Locks, monitors, and deadlocks (LOCKS) . . . 267Threads and stack trace (THREADS) . . . . 268Stack backtrace . . . . . . . . . . . . 270Shared Classes (SHARED CLASSES) . . . . 271Classloaders and Classes (CLASSES) . . . . 272

Environment variables and Javadump . . . . . 273

Chapter 26. Using Heapdump . . . . 275Getting Heapdumps . . . . . . . . . . . 275

Enabling text formatted (classic) Heapdumps 275Available tools for processing Heapdumps . . . 276Using -Xverbose:gc to obtain heap information . . 276Environment variables and Heapdump. . . . . 276Text (classic) Heapdump file format . . . . . . 277

Chapter 27. Using system dumps andthe dump viewer . . . . . . . . . . 281Overview of system dumps . . . . . . . . 281System dump defaults . . . . . . . . . . 282Using the dump viewer . . . . . . . . . . 282

Problems to tackle with the dump viewer . . . 285Commands for use with jdmpview . . . . . 285Example session . . . . . . . . . . . 290jdmpview commands quick reference . . . . 296

Chapter 28. Tracing Java applicationsand the JVM . . . . . . . . . . . . 299

vi IBM SDK for Java: Diagnostics Guide

What can be traced? . . . . . . . . . . . 299Types of tracepoint . . . . . . . . . . . 300Default tracing . . . . . . . . . . . . . 300Where does the data go? . . . . . . . . . 301

Writing trace data to memory buffers . . . . 302Writing trace data to a file . . . . . . . . 302External tracing . . . . . . . . . . . 303Tracing to stderr . . . . . . . . . . . 303Trace combinations . . . . . . . . . . 303

Controlling the trace . . . . . . . . . . . 303Specifying trace options . . . . . . . . . 304Detailed descriptions of trace options . . . . 304Using the Java API . . . . . . . . . . 319

Using the trace formatter . . . . . . . . . 319Determining the tracepoint ID of a tracepoint . . 320Application trace . . . . . . . . . . . . 321

Implementing application trace . . . . . . 322Using application trace at runtime . . . . . 324

Using method trace . . . . . . . . . . . 325Running with method trace . . . . . . . 325Untraceable methods . . . . . . . . . . 326Examples of use . . . . . . . . . . . 328Example of method trace . . . . . . . . 329

Chapter 29. JIT and AOT problemdetermination . . . . . . . . . . . 331Diagnosing a JIT or AOT problem . . . . . . 331

Disabling the JIT or AOT compiler . . . . . 331Selectively disabling the JIT or AOT compiler 332Locating the failing method . . . . . . . 333Identifying JIT compilation failures . . . . . 335Identifying AOT compilation failures . . . . 336

Performance of short-running applications . . . 336JVM behavior during idle periods . . . . . . 336

Chapter 30. The Diagnostics Collector 339Using the Diagnostics Collector . . . . . . . 339Using the -Xdiagnosticscollector option. . . . . 339Collecting diagnostics from Java runtime problems 339Verifying your Java diagnostics configuration. . . 341Configuring the Diagnostics Collector . . . . . 341

Diagnostics Collector settings . . . . . . . 341Known limitations. . . . . . . . . . . . 343

Chapter 31. Garbage Collectordiagnostics . . . . . . . . . . . . 345How do the garbage collectors work? . . . . . 345Common causes of perceived leaks . . . . . . 345

Listeners . . . . . . . . . . . . . . 345Hash tables . . . . . . . . . . . . . 346Static class data . . . . . . . . . . . 346JNI references . . . . . . . . . . . . 346Objects with finalizers . . . . . . . . . 346

-verbose:gc logging . . . . . . . . . . . 346Global collections . . . . . . . . . . . 347Garbage collection triggered by System.gc() . . 348Allocation failures . . . . . . . . . . . 349Scavenger collections . . . . . . . . . . 351Concurrent garbage collection . . . . . . . 352Timing problems during garbage collection . . 356

-Xtgc tracing . . . . . . . . . . . . . 357-Xtgc:backtrace . . . . . . . . . . . . 357-Xtgc:compaction . . . . . . . . . . . 357-Xtgc:concurrent . . . . . . . . . . . 357-Xtgc:dump . . . . . . . . . . . . . 358-Xtgc:excessiveGC . . . . . . . . . . . 358-Xtgc:freelist . . . . . . . . . . . . . 359-Xtgc:parallel . . . . . . . . . . . . 359-Xtgc:references. . . . . . . . . . . . 359-Xtgc:scavenger. . . . . . . . . . . . 360-Xtgc:terse . . . . . . . . . . . . . 360

Finding which methods allocated large objects . . 361

Chapter 32. Class-loader diagnostics 363Class-loader command-line options . . . . . . 363Class-loader runtime diagnostics . . . . . . . 363Loading from native code . . . . . . . . . 364

Chapter 33. Shared classesdiagnostics . . . . . . . . . . . . 367Deploying shared classes . . . . . . . . . 367

Cache naming . . . . . . . . . . . . 367Cache access . . . . . . . . . . . . 368Cache housekeeping . . . . . . . . . . 368Cache performance . . . . . . . . . . 369Compatibility between service releases . . . . 372Nonpersistent shared cache cleanup . . . . . 373

Dealing with runtime bytecode modification . . . 374Potential problems with runtime bytecodemodification. . . . . . . . . . . . . 374Modification contexts. . . . . . . . . . 375SharedClassHelper partitions . . . . . . . 375Using the safemode option . . . . . . . . 375JVMTI redefinition and retransformation ofclasses. . . . . . . . . . . . . . . 376Further considerations for runtime bytecodemodification. . . . . . . . . . . . . 376

Understanding dynamic updates . . . . . . . 377Using the Java Helper API . . . . . . . . . 379

SharedClassHelper api . . . . . . . . . 380Understanding shared classes diagnostics output 381

Verbose output . . . . . . . . . . . . 382VerboseIO output . . . . . . . . . . . 382VerboseHelper output . . . . . . . . . 382verboseAOT output . . . . . . . . . . 383printStats utility . . . . . . . . . . . 383printAllStats utility . . . . . . . . . . 385

Debugging problems with shared classes . . . . 386Using shared classes trace . . . . . . . . 386Why classes in the cache might not be found orstored . . . . . . . . . . . . . . . 386Dealing with initialization problems . . . . . 387Dealing with verification problems . . . . . 389Dealing with cache problems . . . . . . . 390

Class sharing with OSGi ClassLoading framework 390

Chapter 34. Using the Reliability,Availability, and ServiceabilityInterface . . . . . . . . . . . . . 391Preparing to use JVMRI . . . . . . . . . . 391

Contents vii

||||||||||||||||

Writing an agent . . . . . . . . . . . 391Registering a trace listener . . . . . . . . 392Changing trace options . . . . . . . . . 393Starting the agent . . . . . . . . . . . 393Building the agent. . . . . . . . . . . 394Agent design . . . . . . . . . . . . 394

JVMRI functions . . . . . . . . . . . . 394API calls provided by JVMRI . . . . . . . . 395

CreateThread . . . . . . . . . . . . 395DumpDeregister . . . . . . . . . . . 395DumpRegister . . . . . . . . . . . . 395DynamicVerbosegc . . . . . . . . . . 396GenerateHeapdump . . . . . . . . . . 396GenerateJavacore . . . . . . . . . . . 396GetComponentDataArea. . . . . . . . . 396GetRasInfo . . . . . . . . . . . . . 397InitiateSystemDump . . . . . . . . . . 397InjectOutOfMemory . . . . . . . . . . 397InjectSigSegv . . . . . . . . . . . . 397NotifySignal . . . . . . . . . . . . . 398ReleaseRasInfo . . . . . . . . . . . . 398RunDumpRoutine . . . . . . . . . . . 398SetOutOfMemoryHook . . . . . . . . . 398TraceDeregister . . . . . . . . . . . . 399TraceDeregister50 . . . . . . . . . . . 399TraceRegister . . . . . . . . . . . . 399TraceRegister50 . . . . . . . . . . . . 400TraceResume . . . . . . . . . . . . 400TraceResumeThis . . . . . . . . . . . 400TraceSet . . . . . . . . . . . . . . 400TraceSnap . . . . . . . . . . . . . 401TraceSuspend . . . . . . . . . . . . 401TraceSuspendThis . . . . . . . . . . . 401

RasInfo structure . . . . . . . . . . . . 401RasInfo request types. . . . . . . . . . . 402Intercepting trace data . . . . . . . . . . 402

The -Xtrace:external=. . . . . . . 402Calling external trace . . . . . . . . . . 403

Formatting . . . . . . . . . . . . . . 403

Chapter 35. Using the HPROF Profiler 405Explanation of the HPROF output file . . . . . 406

Chapter 36. Using the JVMTI . . . . . 411

Chapter 37. Using the Diagnostic ToolFramework for Java . . . . . . . . 413Using the DTFJ interface . . . . . . . . . 414DTFJ example application . . . . . . . . . 417

Chapter 38. Using JConsole . . . . . 421

Part 5. Appendixes . . . . . . . . 425

Appendix A. CORBA minor codes . . 427

Appendix B. Environment variables 429Displaying the current environment . . . . . . 429Setting an environment variable . . . . . . . 429Separating values in a list . . . . . . . . . 430JVM environment settings . . . . . . . . . 430z/OS environment variables . . . . . . . . 433

Appendix C. Messages . . . . . . . 435DUMP messages . . . . . . . . . . . . 436J9VM messages. . . . . . . . . . . . . 439JITM messages . . . . . . . . . . . . . 444SHRC messages . . . . . . . . . . . . 445J9GC messages . . . . . . . . . . . . . 461

Appendix D. Command-line options 465Specifying command-line options. . . . . . . 465General command-line options . . . . . . . 466System property command-line options . . . . 467JVM command-line options. . . . . . . . . 468

-XX command-line options . . . . . . . . 479JIT and AOT command-line options . . . . . . 480Garbage Collector command-line options . . . . 482

Appendix E. Default settings for theJVM . . . . . . . . . . . . . . . 489

Notices . . . . . . . . . . . . . . 491Trademarks . . . . . . . . . . . . . . 492

Index . . . . . . . . . . . . . . . 495

viii IBM SDK for Java: Diagnostics Guide

Figures1. Screenshot of ReportEnv tool . . . . . . 154 2. DTFJ interface diagram . . . . . . . . 416

Copyright IBM Corp. 2003, 2009 ix

x IBM SDK for Java: Diagnostics Guide

Tables

Copyright IBM Corp. 2003, 2009 xi

xii IBM SDK for Java: Diagnostics Guide

About the Diagnostics GuideThe Diagnostics Guide tells you about how the IBM Virtual Machine for Java

works, debugging techniques, and the diagnostic tools that are available to helpyou solve problems with JVMs. It also gives guidance on how to submit problemsto IBM.

What does the Java Virtual Machine (JVM) mean?The Java Virtual machine (JVM) is the application that executes a Java programand it is included in the Java package.

The installable Java package supplied by IBM comes in two versions on Linux

and Windows platforms:v The Java Runtime Environment (JRE)v The Java Software Development Kit (SDK)The AIX, z/OS, and i5/OS platforms ship only the SDK.

The JRE provides runtime support for Java applications. The SDK provides theJava compiler and other development tools. The SDK includes the JRE.

The JRE (and, therefore, the SDK) includes a JVM. This is the application thatexecutes a Java program. A Java program requires a JVM to run on a particularplatform, such as Linux, z/OS, or Windows.

The IBM SDK, Version 5.0 contains a different implementation of the JVM and theJust-In-Time compiler (JIT) from most earlier releases of the IBM SDK, apart fromthe version 1.4.2 implementation on z/OS 64-bit and on AMD64/EM64T platforms.You can identify this implementation in the output from the java -versioncommand, which gives these strings for the different implementations:

Implementation Output

5.0 IBM J9 VM (build 2.3, J2RE 1.5.0 IBM...

6 IBM J9 VM (build 2.4, J2RE 1.6.0 IBM...

1.4.2 classic Classic VM (build 1.4.2, J2RE 1.4.2 IBM...

1.4.2 on z/OS 64-bit andAMD64/EM64T platforms

IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM...

i5/OS classic 1.3.1 java version "1.3.1"Java(TM) 2 Runtime Environment, Standard Edition (build ...)Classic VM (build 1.3, build JDK-1.3, native threads, jitc_de)



i5/OS classic 1.6.0 java version "1.6.0"Java(TM) SE Runtime Environment (build ...)Classic VM (build 1.6, build JDK-1.6, native threads, jitc_de)

Copyright IBM Corp. 2003, 2009 xiii

For Diagnostics Guides that describe earlier IBM SDKs, see http://www.ibm.com/developerworks/java/jdk/diagnosis/. For earlier versions of the i5/OS ClassicJVM, see the iSeries Information Center at http://publib.boulder.ibm.com/infocenter/iseries/v5r4/.

Who should read this bookThis book is for anyone who is responsible for solving problems with Java.

Using this bookBefore you can use this book, you must have a good understanding of SoftwareDeveloper Kits and the Runtime Environment.

This book is to be used with the IBM SDK and Runtime Environment Version 6.Check the full version of your installed JVM. If you do not know how to do this,see Chapter 13, First steps in problem determination, on page 99. Some of thediagnostic tools described in this book do not apply to earlier versions.

You can use this book in three ways:v As an overview of how the IBM Virtual Machine for Java operates, withemphasis on the interaction with Java. Part 1, Understanding the IBM SDK forJava, on page 1 of the book provides this information. You might find thisinformation helpful when you are designing your application.

v As straightforward guide to determining a problem type, collecting thenecessary diagnostic data, and sending it to IBM. Part 2, Submitting problemreports, on page 83 and Part 3, Problem determination, on page 97 of thebook provide this information.

v As the reference guide to all the diagnostic tools that are available in the IBMVirtual Machine for Java. This information is given in Part 4, Using diagnostictools, on page 227 of the book.

The parts overlap in some ways. For example, Part 3, Problem determination, onpage 97 refers to chapters that are in Part 4, Using diagnostic tools, on page 227when those chapters describe the diagnostics data that is required. You will be ableto more easily understand some of the diagnostics that are in Part 4, Usingdiagnostic tools, on page 227 if you read the appropriate chapter in Part 1,Understanding the IBM SDK for Java, on page 1.

The appendixes provide supporting reference information that is gathered intoconvenient tables and lists.

Other sources of informationYou can obtain additional information about the latest tools and documentation,Java documentation and the IBM SDKs by following the links.v For the latest tools and documentation, see IBM developerWorks at:

http://www.ibm.com/developerworks/java/v For Java documentation, see:

http://java.sun.com/reference/docs/index.htmlv For the IBM SDKs, see the downloads at:

xiv IBM SDK for Java: Diagnostics Guide

http://www.ibm.com/developerworks/java/jdk/index.html

Reporting problems in the JVMIf you want to send a problem report, you should understand which sectionsdescribe how to do so.

If you want to use this Information Center only to determine your problem and tosend a problem report to IBM, go to Part 3, Problem determination, on page 97,and to the section that relates to your platform. Go to the section that describes thetype of problem that you are having. This section might offer advice about how tocorrect the problem, and might also offer workarounds. The section will also tellyou what data IBM service needs you to collect to diagnose the problem. Collectthe data and send a problem report and associated data to IBM service, asdescribed in Part 2, Submitting problem reports, on page 83.

Conventions and terminologySpecific conventions are used to describe methods and classes, and command-lineoptions.

Methods and classes are shown in normal font:v The serviceCall() methodv The StreamRemoteCall class

Command-line options are shown in bold. For example:v -Xgcthreads

Options shown with values in braces signify that one of the values must bechosen. For example:

-Xverify:{remote | all | none}

with the default underscored.

Options shown with values in brackets signify that the values are optional. Forexample:

-Xrunhprof[:help][=...]

In this information, any reference to Sun is intended as a reference to SunMicrosystems, Inc.

How to send your commentsYour feedback is important in helping to provide accurate and useful information.

If you have any comments about this Diagnostics Guide, you can send them bye-mail to [email protected]. Include the name of the Diagnostics Guide, theplatform you are using, the version of your JVM, and, if applicable, the specificlocation of the text you are commenting on (for example, the title of the page).

Do not use this method for sending in bug reports on the JVM. For these, use theusual methods, as described in Part 2, Submitting problem reports, on page 83.

About the Diagnostics Guide xv

ContributorsThis Diagnostics Guide has been put together by members of the Java TechnologyCenter IBM development and service departments in Hursley, Bangalore, Austin,Toronto, Ottawa, and Rochester.

Summary of changesThis topic introduces whats new for this Version 6 Diagnostics Guide. This Version6 Diagnostics Guide is based on the Diagnostics Guide for Java 5.0 for the IBMDeveloper Kit and Runtime Environment, Java 2 Technology Edition, Version 5.0.

To help people migrating from Version 5.0, technical changes made for this editionare indicated by revision bars to the left of the changes, or contained inside bluechevrons.

For the sixth edition

The significant changes in this edition are:v Description of -Dcom.ibm.tools.attach.enable=yes in System propertycommand-line options on page 467.

v Description of Chapter 30, The Diagnostics Collector, on page 339 and the-Xdiagnosticscollector[:settings=] option in JVM command-lineoptions on page 468.

For the third edition

The most significant changes are:v Changes to information about compressed references, Compressed referenceson page 11.

v Information about the new global shared class filter, Applying a global filteron page 381.

v Information about selective debugging, see -XselectiveDebug in JVMcommand-line options on page 468.

v Changes to the JAVA_DUMP_OPTS environment variable, Dump agentenvironment variables on page 255.

v Information about diagnostics output provided when all dump agents aredisabled, Removing dump agents on page 254.

v Information about default dump agents specific to z/OS platforms, z/OSspecifics on page 257.

v Information about the LE CEEDUMP dump agent, LE CEEDUMPs on page244.

v Instructions on triggering an SVC dump to work around problems with failingIEATDUMPS, Failing transaction dumps (IEATDUMPs) on page 166.

v Changes to the z/OS requirements for using large page support, see -Xlp inJVM command-line options on page 468.

For the second edition

The most significant changes are:v Addition of compressed references information, Compressed references onpage 11.

v Addition of split heap information, Split heap on page 21.

xvi IBM SDK for Java: Diagnostics Guide

|||||||

v Addition of a before and after soft, weak, and phantom reference count in-verbose:gc output, New area allocation failures on page 349.

v Addition of a shared classes section in the Javadump examples, Shared Classes(SHARED CLASSES) on page 271.

v Addition of a list of methods that method trace cannot trace, Untraceablemethods on page 326.

v Addition of the JavaReference class to the DTFJ overview diagram, Using theDTFJ interface on page 414.

v Updated messages in Appendix C, Messages, on page 435.

For the first edition

The most significant changes are:v Addition of AOT information in Chapter 6, The AOT compiler, on page 41and Chapter 29, JIT and AOT problem determination, on page 331.

v Addition of persistent shared data cache information in Chapter 4, Class datasharing, on page 35 and Chapter 33, Shared classes diagnostics, on page 367.

v Updated jdmpview tool in Chapter 27, Using system dumps and the dumpviewer, on page 281.

v Updated messages in Appendix C, Messages, on page 435.

About the Diagnostics Guide xvii

xviii IBM SDK for Java: Diagnostics Guide

Part 1. Understanding the IBM SDK for JavaThe information in this section of the Information Center will give you a basicunderstanding of the SDK.

It provides:v Background information to explain why some diagnostics work the way they dov Useful information for application designersv An explanation of some parts of the JVM

Garbage collection techniques in general are complex. For that reason, the garbagecollection set of topics are longer than most of the others.

Other sections provide a summary, especially where guidelines about the use ofthe SDK are appropriate. This part is not intended as a description of the design ofthe SDK, except that it might influence application design or promote anunderstanding of why things are done the way that they are.

This part also provides a section that describes the IBM Object Request Broker(ORB) component.

The sections in this part are:v Chapter 1, The building blocks of the IBM Virtual Machine for Java, on page 3v Chapter 2, Memory management, on page 7v Chapter 3, Class loading, on page 31v Chapter 4, Class data sharing, on page 35v Chapter 5, The JIT compiler, on page 37v Chapter 7, Java Remote Method Invocation, on page 43v Chapter 8, The ORB, on page 47v Chapter 9, The Java Native Interface (JNI), on page 71

Copyright IBM Corp. 2003, 2009 1

2 IBM SDK for Java: Diagnostics Guide

Chapter 1. The building blocks of the IBM Virtual Machine forJava

The IBM Virtual Machine for Java (JVM) is a core component of the Java RuntimeEnvironment (JRE) from IBM. The JVM is a virtualized computing machine thatfollows a well-defined specification for the runtime requirements of the Javaprogramming language.

The JVM is called virtual because it provides a machine interface that does notdepend on the underlying operating system and machine hardware architecture.This independence from hardware and operating system is a cornerstone of thewrite-once run-anywhere value of Java programs. Java programs are compiled intobytecodes that target the abstract virtual machine; the JVM is responsible forexecuting the bytecodes on the specific operating system and hardwarecombinations.

The JVM specification also defines several other runtime characteristics. All JVMs:v Execute code that is defined by a standard known as the class file formatv Provide fundamental runtime security such as bytecode verificationv Provide intrinsic operations such as performing arithmetic and allocating newobjects

JVMs that implement the specification completely and correctly are calledcompliant. The IBM Virtual Machine for Java is certified as compliant. Not allcompliant JVMs are identical. JVM implementers have a wide degree of freedom todefine characteristics that are beyond the scope of the specification. For example,implementers might choose to favour performance or memory footprint; theymight design the JVM for rapid deployment on new platforms or for variousdegrees of serviceability.

All the JVMs that are currently used commercially come with a supplementarycompiler that takes bytecodes and produces platform-dependent machine code.This compiler works with the JVM to select parts of the Java program that couldbenefit from the compilation of bytecode, and replaces the JVMs virtualizedinterpretation of these areas of bytecode with concrete code. This is calledjust-in-time (JIT) compilation. IBMs JIT compiler is described in Chapter 5, TheJIT compiler, on page 37.

This Diagnostics Guide is not a JVM specification; it discusses the characteristics ofthe IBM JRE that might affect the non-functional behavior of your Java program.This guide also provides information to assist you with tracking down problemsand offers advice, from the point of view of the JVM implementer, on how you cantune your applications. There are many other sources for good advice about Javaperformance, descriptions of the semantics of the Java runtime libraries, and toolsto profile and analyze in detail the execution of applications.


Java application stackA Java application uses the Java class libraries that are provided by the JRE toimplement the application-specific logic. The class libraries, in turn, areimplemented in terms of other class libraries and, eventually, in terms of primitivenative operations that are provided directly by the JVM. In addition, someapplications must access native code directly.

The following diagram shows the components of a typical Java Application Stackand the IBM JRE.

The JVM facilitates the invocation of native functions by Java applications and anumber of well-defined Java Native Interface functions for manipulating Java fromnative code (for more information, see Chapter 9, The Java Native Interface (JNI),on page 71).

Components of the IBM Virtual Machine for JavaThe IBM Virtual Machine for Java technology comprises a set of components.

The following diagram shows component structure of the IBM Virtual Machine forJava:

Java Application

Java Application Stack

Java

Code

Nativ

e Co

de

Java ClassExtensions

Class Libraries ORB

Platform

IBM JVM

Native Libraries

Others

NativeOpt.Packages

UserNativeExts.


JVM APIThe JVM API encapsulates all the interaction between external programs and theJVM.

Examples of this interaction include:v Creation and initialization of the JVM through the invocation APIs.v Interaction with the standard Java launchers, including handling command-linedirectives.

v Presentation of public JVM APIs such as JNI and JVMTI.v Presentation and implementation of private JVM APIs used by core Java classes.

Diagnostics componentThe diagnostics component provides Reliability, Availability, and Serviceability(RAS) facilities to the JVM.

The IBM Virtual Machine for Java is distinguished by its extensive RAScapabilities. The IBM Virtual Machine for Java is designed to be deployed inbusiness-critical operations and includes several trace and debug utilities to assistwith problem determination.

If a problem occurs in the field, it is possible to use the capabilities of thediagnostics component to trace the runtime function of the JVM and help toidentify the cause of the problem. The diagnostics component can produce outputselectively from various parts of the JVM and the JIT. Part 4, Using diagnostictools, on page 227 describes various uses of the diagnostics component.

Memory managementThe memory management component is responsible for the efficient use of systemmemory by a Java application.

Java programs run in a managed execution environment. When a Java programrequires storage, the memory management component allocates the application adiscrete region of unused memory. After the application no longer refers to the

JVM API

Diagnostics Memorymanagement Class loader Interpreter

Platform port layer

Chapter 1. The building blocks of the IBM Virtual Machine for Java 5

storage, the memory management component must recognize that the storage isunused and reclaim the memory for subsequent reuse by the application or returnit to the operating system.

The memory management component has several policy options that you canspecify when you deploy the application. Chapter 2, Memory management, onpage 7 discusses memory management in the IBM Virtual Machine for Java.

Class loaderThe class loader component is responsible for supporting Javas dynamic codeloading facilities.

The dynamic code loading facilities include:v Reading standard Java .class files.v Resolving class definitions in the context of the current runtime environment.v Verifying the bytecodes defined by the class file to determine whether thebytecodes are language-legal.

v Initializing the class definition after it is accepted into the managed runtimeenvironment.

v Various reflection APIs for introspection on the class and its defined members.

InterpreterThe interpreter is the implementation of the stack-based bytecode machine that isdefined in the JVM specification. Each bytecode affects the state of the machineand, as a whole, the bytecodes define the logic of the application.

The interpreter executes bytecodes on the operand stack, calls native functions,contains and defines the interface to the JIT compiler, and provides support forintrinsic operations such as arithmetic and the creation of new instances of Javaclasses.

The interpreter is designed to execute bytecodes very efficiently. It can switchbetween running bytecodes and handing control to the platform-specificmachine-code produced by the JIT compiler. The JIT compiler is described inChapter 5, The JIT compiler, on page 37.

Platform port layerThe ability to reuse the code for the JVM for numerous operating systems andprocessor architectures is made possible by the platform port layer.

The platform port layer is an abstraction of the native platform functions that arerequired by the JVM. Other components of the JVM are written in terms of theplatform-neutral platform port layer functions. Further porting of the JVM requiresthe provision of implementations of the platform port layer facilities.


Chapter 2. Memory managementThis description of the Garbage Collector and Allocator provides backgroundinformation to help you diagnose problems with memory management.

Memory management is explained under these headings:v Overview of memory managementv Allocation on page 9v Detailed description of garbage collection on page 12v Generational Concurrent Garbage Collector on page 20v How to do heap sizing on page 22v Interaction of the Garbage Collector with applications on page 24v How to coexist with the Garbage Collector on page 24v Frequently asked questions about the Garbage Collector on page 27

For detailed information about diagnosing Garbage Collector problems, seeChapter 31, Garbage Collector diagnostics, on page 345.

See also the reference information in Garbage Collector command-line options onpage 482.

Overview of memory managementMemory management contains the Garbage Collector and the Allocator. It isresponsible for allocating memory in addition to collecting garbage. Because thetask of memory allocation is small, compared to that of garbage collection, theterm garbage collection usually also means memory management.

This section includes:v A summary of some of the diagnostic techniques related to memorymanagement.

v An understanding of the way that the Garbage Collector works, so that you candesign applications accordingly.

The Garbage Collector allocates areas of storage in the heap. These areas of storagedefine Java objects. When allocated, an object continues to be live while a reference(pointer) to it exists somewhere in the JVM; therefore the object is reachable. Whenan object ceases to be referenced from the active state, it becomes garbage and canbe reclaimed for reuse. When this reclamation occurs, the Garbage Collector mustprocess a possible finalizer and also ensure that any internal JVM resources thatare associated with the object are returned to the pool of such resources.

Object allocationObject allocation is driven by requests by applications, class libraries, and the JVMfor storage of Java objects, which can vary in size and require different handling.

Every allocation requires a heap lock to be acquired to prevent concurrent threadaccess. To optimize this allocation, particular areas of the heap are dedicated to athread, known as the TLH (thread local heap), and that thread can allocate from itsTLH without having to lock out other threads. This technique delivers the best


possible allocation performance for small objects. Objects are allocated directlyfrom a thread local heap. A new object is allocated from this cache withoutneeding to grab the heap lock. All objects less than 512 bytes (768 bytes on 64-bitJVMs) are allocated from the cache. Larger objects are allocated from the cache ifthey can be contained in the existing cache. This cache is often referred to as thethread local heap or TLH.

Reachable objectsReachable objects are found using frames on the thread stack, roots and references.

The active state of the JVM is made up of the set of stacks that represents thethreads, the statics that are inside Java classes, and the set of local and global JNIreferences. All functions that are called inside the JVM itself cause a frame on thethread stack. This information is used to find the roots. A root is an object whichhas a reference to it from outside the heap. These roots are then used to findreferences to other objects. This process is repeated until all reachable objects arefound.

Garbage collectionWhen the JVM cannot allocate an object from the heap because of lack ofcontiguous space, a memory allocation fault occurs, and the Garbage Collector iscalled.

The first task of the Garbage Collector is to collect all the garbage that is in theheap. This process starts when any thread calls the Garbage Collector eitherindirectly as a result of allocation failure, or directly by a specific call toSystem.gc(). The first step is to acquire exclusive control on the virtual machine toprevent any further Java operations. Garbage collection can then begin.

Heap sizing problemsIf the operation of the heap, using the default settings, does not give the bestresults for your application, there are actions that you can take.

For the majority of applications, the default settings work well. The heap expandsuntil it reaches a steady state, then remains in that state, which should give a heapoccupancy (the amount of live data on the heap at any given time) of 70%. At thislevel, the frequency and pause time of garbage collection should be acceptable.

For some applications, the default settings might not give the best results. Listedhere are some problems that might occur, and some suggested actions that you cantake. Use verbose:gc to help you monitor the heap.

The frequency of garbage collections is too high until the heap reaches a steadystate.

Use verbose:gc to determine the size of the heap at a steady state and set -Xmsto this value.

The heap is fully expanded and the occupancy level is greater than 70%.Increase the -Xmx value so that the heap is not more than 70% occupied, butfor best performance try to ensure that the heap never pages. The maximumheap size should, if possible, be able to be contained in physical memory toavoid paging.

At 70% occupancy the frequency of garbage collections is too great.Change the setting of -Xminf. The default is 0.3, which tries to maintain 30%


free space by expanding the heap. A setting of 0.4, for example, increases thisfree space target to 40%, and reduces the frequency of garbage collections.

Pause times are too long.Try using -Xgcpolicy:optavgpause. This reduces the pause times and makesthem more consistent when the heap occupancy rises. It does, however, reducethroughput by approximately 5%, although this value varies with differentapplications.

Here are some useful tips:v Ensure that the heap never pages; that is, the maximum heap size must be ableto be contained in physical memory.

v Avoid finalizers. You cannot guarantee when a finalizer will run, and often theycause problems. If you do use finalizers, try to avoid allocating objects in thefinalizer method. A verbose:gc trace shows whether finalizers are being called.

v Avoid compaction. A verbose:gc trace shows whether compaction is occurring.Compaction is usually caused by requests for large memory allocations. Analyzerequests for large memory allocations and avoid them if possible. If they arelarge arrays, for example, try to split them into smaller arrays.

AllocationThe memory management component contains the Garbage Collector and theAllocator. The task of memory allocation is small, compared to that of garbagecollection.

Heap lock allocationHeap lock allocation occurs when the allocation request cannot be satisfied in theexisting cache.

For a description of cache allocation, when the request cannot be satisfied, seeCache allocation. As its name implies, heap lock allocation requires a lock and istherefore avoided, if possible, by using the cache.

If the Garbage Collector cannot find a big enough chunk of free storage, allocationfails and the Garbage Collector must perform a garbage collection. After a garbagecollection cycle, if the Garbage Collector created enough free storage, it searchesthe freelist again and picks up a free chunk. The heap lock is released either afterthe object has been allocated, or if not enough free space is found. If the GarbageCollector does not find enough free storage, it returns OutOfMemoryError.

Cache allocationCache allocation is specifically designed to deliver the best possible allocationperformance for small objects. Objects are allocated directly from a thread localallocation buffer that the thread has previously allocated from the heap. A newobject is allocated from this cache without the need to grab the heap lock;therefore, cache allocation is very efficient.

All objects less than 512 bytes (768 bytes on 64-bit JVMs) are allocated from thecache. Larger objects are allocated from the cache if they can be contained in theexisting cache; if not a locked heap allocation is performed.

The cache block is sometimes called a thread local heap (TLH). The size of theTLH varies from 512 bytes (768 on 64-bit JVMs) to 128 KB, depending on the

Chapter 2. Memory management 9

allocation rate of the thread.Threads which allocate lots of objects are given largerTLHs to further reduce contention on the heap lock.

Large Object AreaAs objects are allocated and freed, the heap can become fragmented in such a waythat allocation can be met only by time-consuming compactions. This problem ismore pronounced if an application allocates large objects. In an attempt to alleviatethis problem, the large object area (LOA) is allocated.

The LOA is an area of the tenure area of the heap set used solely to satisfyallocations for large objects that cannot be satisfied in the main area of the tenureheap, which is referred to in the rest of this section as the small object area (SOA).A large object in this context is considered to be any object 64 KB or greater in size;allocations for new TLH objects are not considered to be large objects. The largeobject area is allocated by default for all GC polices except -Xgcpolicy:subpool (forAIX, Linux PPC and zSeries, z/OS, and i5/OS) but, if it is not used, it is shrunkto zero after a few collections. It can be disabled explicitly by specifying the-Xnoloa command-line option.

Initialization and the LOAThe LOA boundary is calculated when the heap is initialized, and recalculatedafter every garbage collection. The size of the LOA can be controlled usingcommand-line options: -Xloainitial, -Xloaminimum, and -Xloamaximum.

The options take values between 0 and 0.95 (0% thru 95% of the current tenureheap size). The defaults are:v -Xloainitial0.05 (5%)v -Xloaminimum0 (0%)v -Xloamaximum0.5 (50%)

Expansion and shrinkage of the LOAThe Garbage Collector expands or shrinks the LOA, depending on usage.

The Garbage Collector uses the following algorithm:v If an allocation failure occurs in the SOA: If the current size of the LOA is greater than its initial size and if the amount

of free space in the LOA is greater than 70%, reduce by 1% the percentage ofspace that is allocated to the LOA.

If the current size of the LOA is equal to or less than its initial size, and if theamount of free space in the LOA is greater than 90%:- If the current size of the LOA is greater than 1% of the heap, reduce by 1%the percentage of space that is allocated to the LOA.

- If the current size of the LOA is 1% or less of the heap, reduce by 0.1%, thepercentage of space that is allocated to the LOA.

v If an allocation failure occurs on the LOA: If the size of the allocation request is greater than 20% of the current size of

the LOA, increase the LOA by 1%. If the current size of the LOA is less than its initial size, and if the amount of

free space in the LOA is less than 50%, increase the LOA by 1%. If the current size of the LOA is equal to or greater than its initial size, and if

the amount of free space in the LOA is less than 30%, increase the LOA by1%.


Allocation in the LOAWhen allocating an object, the allocation is first attempted in the SOA. If it is notpossible to find a free entry of sufficient size to satisfy the allocation, and the sizeof the request is equal to or greater than 64 KB, the allocation is tried in the LOAagain. If the size of the request is less than 64 KB or insufficient contiguous spaceexists in the LOA, an allocation failure is triggered.

Compressed referencesWhen using compressed references, the JVM stores all references to objects, classes,threads, and monitors as 32-bit values. Use the -Xcompressedrefs command-lineoption to enable compressed references in a 64-bit JVM. Only 64-bit JVMsrecognize this option.

The use of compressed references improves the performance of many applicationsbecause objects are smaller, resulting in less frequent garbage collection andimproved memory cache utilization. Certain applications might not benefit fromcompressed references. Test the performance of your application with and withoutthe option to determine if it is appropriate.

Using compressed references runs a different version of the JVM. You need toenable compressed references when using the dump extractor to analyze dumpsproduced by the JVM, see Using the dump viewer on page 282.

When you are using compressed references, the following structures are allocatedin the lowest 4 GB of the address space:v Classesv Threadsv MonitorsAdditionally, the operating system and native libraries use some of this addressspace. Small Java heaps are also allocated in the lowest 4 GB of the address space.Larger Java heaps are allocated higher in the address space.

Native memory OutOfMemoryError exceptions might occur when usingcompressed references if the lowest 4 GB of address space becomes full,particularly when loading classes, starting threads, or using monitors. You canoften resolve these errors with a larger -Xmx option to put the Java heap higher inthe address space.

On Windows, the operating system allocates memory in the lowest 4 GB ofaddress space by default until that area is full. A large -Xmx value might beinsufficient to avoid OutOfMemoryError exceptions. Advanced users can changethe default Windows allocation options by setting the registry key namedHKLM\System\CurrentControlSet\Control\Session Manager\MemoryManagement\AllocationPreference to (REG_DWORD) 0x100000. Seehttp://msdn2.microsoft.com/en-us/isv/bb190527.aspx for more information aboutthis registry key.

For Java 6 SR 5 and after, 64-bit JVMs recognize the following Sun options:

-XX:+UseCompressedOopsThis enables compressed references in 64-bit JVMs. It is identical tospecifying the -Xcompressedrefs option.

-XX:-UseCompressedOopsThis prevents use of compressed references in 64-bit JVMs.


||||||

Note: These options are provided to help when porting applications from the SunJVM to the IBM JVM, for 64-bit platforms. The options might not be supported insubsequent releases.

Detailed description of garbage collectionGarbage collection is performed when an allocation failure occurs in heap lockallocation, or if a specific call to System.gc() occurs. The thread that has theallocation failure or the System.gc() call takes control and performs the garbagecollection.

The first step in garbage collection is to acquire exclusive control on the Virtualmachine to prevent any further Java operations. Garbage collection then goesthrough the three phases: mark, sweep, and, if required, compaction. The IBMGarbage Collector is a stop-the-world (STW) operation, because all applicationthreads are stopped while the garbage is collected.

Mark phaseIn mark phase, all the live objects are marked. Because unreachable objects cannotbe identified singly, all the reachable objects must be identified. Therefore,everything else must be garbage. The process of marking all reachable objects isalso known as tracing.

The mark phase uses:v A pool of structures called work packets. Each work packet contains a mark stack.A mark stack contains references to live objects that have not yet been traced.Each marking thread refers to two work packets; an input packet from whichreferences are popped and an output packet to which unmarked objects thathave just been discovered are pushed. References are marked when they arepushed onto the output packet. When the input packet becomes empty, it isadded to a list of empty packets and replaced by a non-empty packet. When theoutput packet becomes full it is added to a list of non-empty packets andreplaced by a packet from the empty list.

v A bit vector called the mark bit array identifies the objects that are reachable andhave been visited. This bit array is allocated by the JVM at startup based on themaximum heap size (-Xmx).The mark bit array contains one bit for each 8 bytesof heap space. The bit that corresponds to the start address for each reachableobject is set when it is first visited.

The first stage of tracing is the identification of root objects. The active state of theJVM is made up of the saved registers for each thread, the set of stacks thatrepresent the threads, the statics that are in Java classes, and the set of local andglobal JNI references. All functions that are called in the JVM itself cause a frameon the C stack. This frame might contain references to objects as a result of eitheran assignment to a local variable, or a parameter that is sent from the caller. Allthese references are treated equally by the tracing routines.

All the mark bits for all root objects are set and references to the roots pushed tothe output work packet. Tracing then proceeds by iteratively popping a referenceoff the marking threads input work packet and then scanning the referenced objectfor references to other objects. If there are any references to unmarked objects, thatis, mark bit is off, the object is marked by setting the appropriate bit in the markbit array and the reference is pushed to the marking threads output work packet.This process continues until all the work packets are on the empty list, at whichpoint all the reachable objects have been identified.


|||

Mark stack overflowBecause the set of work packets has a finite size, it can overflow and the GarbageCollector then performs a series of actions.

If an overflow occurs, the Garbage Collector empties one of the work packets bypopping its references one at a time, and chaining the referenced objects off theirowning class by using the class pointer slot in the object header. All classes withoverflow objects are also chained together. Tracing can then continue as before. If afurther mark stack overflow occurs, more packets are emptied in the same way.

When a marking thread asks for a new non-empty packet and all work packets areempty, the GC checks the list of overflow classes. If the list is not empty, the GCtraverses this list and repopulates a work packet with the references to the objectson the overflow lists. These packets are then processed as described above. Tracingis complete when all the work packets are empty and the overflow list is empty.

Parallel markThe goal of parallel mark is to not degrade mark performance on a uniprocessor,and to increase typical mark performance on a multiprocessor system. Objectmarking is increased through the addition of helper threads that share the use ofthe pool of work packets; for example, full output packets that are returned to thepool by one thread can be picked up as new input packets by another thread.

Parallel mark still requires the participation of one application thread that is usedas the master coordinating agent. This thread performs very much as it always did,but the helper threads assist both in the identification of the root pointers for thecollection and in the tracing of these roots. Mark bits are updated by using hostmachine atomic primitives that require no additional lock.

By default, a platform with n processors also has n-1 new helper threads, thatwork with the master thread to complete the marking phase of garbage collection.You can override the default number of threads by using the -Xgcthreads option. Ifyou specify a value of 1, there will be no helper threads. The -Xgcthreads optionaccepts any value greater than 0, but clearly you gain nothing by setting it to morethan N-1.

Concurrent markConcurrent mark gives reduced and consistent garbage collection pause timeswhen heap sizes increase. It starts a concurrent marking phase before the heap isfull. In the concurrent phase, the Garbage Collector scans the roots, i.e. stacks, JNIreferences, class statics, and so on. The stacks are scanned by asking each thread toscan its own stack. These roots are then used to trace live objects concurrently.Tracing is done by a low-priority background thread and by each applicationthread when it does a heap lock allocation.

While the Garbage Collector is marking live objects concurrently with applicationthreads running, it has to record any changes to objects that are already traced. Ituses a write barrier that is run every time a reference in an object is updated. Thewrite barrier flags when an object reference update has occurred, to force a rescanof part of the heap. The heap is divided into 512-byte sections and each section isallocated a one-byte card in the card table. Whenever a reference to an object isupdated, the card that corresponds to the start address of the object that has beenupdated with the new object reference is marked with 0x01. A byte is used insteadof a bit to eliminate contention; it allows marking of the cards using non-atomicoperations. An STW collection is started when one of the following occurs:v An allocation failure


v A System.gcv Concurrent mark completes all the marking that it can do

The Garbage Collector tries to start the concurrent mark phase so that it completesat the same time as the heap is exhausted. The Garbage Collector does this byconstant tuning of the parameters that govern the concurrent mark time. In theSTW phase, the Garbage Collector rescans all roots and uses the marked cards tosee what else must be retraced, and then sweeps as normal. It is guaranteed thatall objects that were unreachable at the start of the concurrent phase are collected.It is not guaranteed that objects that become unreachable during the concurrentphase are collected. Objects which become unreachable during the concurrentphase are referred to as floating garbage.

Reduced and consistent pause times are the benefits of concurrent mark, but theycome at a cost. Application threads must do some tracing when they are requestinga heap lock allocation. The processor usage needed varies depending on howmuch idle CPU time is available for the background thread. Also, the write barrierrequires additional processor usage.

The -Xgcpolicy command-line parameter is used to enable and disable concurrentmark:

-Xgcpolicy:

The -Xgcpolicy options have these effects:

optthruputDisables concurrent mark. If you do not have pause time problems (as seenby erratic application response times), you get the best throughput withthis option. Optthruput is the default setting.

optavgpauseEnables concurrent mark with its default values. If you are havingproblems with erratic application response times that are caused by normalgarbage collections, you can reduce those problems at the cost of somethroughput, by using the optavgpause option.

genconRequests the combined use of concurrent and generational GC to helpminimize the time that is spent in any garbage collection pause.

subpoolDisables concurrent mark. It uses an improved object allocation algorithmto achieve better performance when allocating objects on the heap. Thisoption might improve performance on SMP systems with 16 or moreprocessors. The subpool option is available only on AIX, Linux PPC andzSeries, z/OS, and i5/OS.

Sweep phaseOn completion of the mark phase the mark bit vector identifies the location of allthe live objects in the heap. The sweep phase uses this to identify those chunks ofheap storage that can be reclaimed for future allocations; these chunks are addedto the pool of free space. To avoid filling this free space pool with lots of smallchunks of storage, only chunks of at least a certain size are reclaimed and added tothe free pool. The minimum size for a free chunk is currently defined as 512 bytes(768 bytes on 64-bit platforms).


A free chunk is identified by examining the mark bit vector looking for sequencesof zeros, which identify possible free space. GC ignores any sequences of zeros thatcorrespond to a length less than the minimum free size. When a sequence ofsufficient length is found, the Garbage Collector checks the length of the object atthe start of the sequence to determine the actual amount of free space that can bereclaimed. If this amount is greater than or equal to the minimum size for a freechunk, it is reclaimed and added to the free space pool.

The small areas of storage that are not on the freelist are known as dark matter,and they are recovered when the objects that are next to them become free, orwhen the heap is compacted. It is not necessary to free the individual objects in thefree chunk, because it is known that the whole chunk is free storage. When achunk is freed, the Garbage Collector has no knowledge of the objects that were init.

Parallel bitwise sweepParallel bitwise sweep improves the sweep time by using available processors. Inparallel bitwise sweep, the Garbage Collector uses the same helper threads that areused in parallel mark, so the default number of helper threads is also the same andcan be changed with the -Xgcthreads option.

The heap is divided into sections of 256 KB and each thread (helper or master)takes a section at a time and scans it, performing a modified bitwise sweep. Theresults of this scan are stored for each section. When all sections have beenscanned, the freelist is built.

Concurrent sweepLike concurrent mark, concurrent sweep gives reduced garbage collection pausetimes when heap sizes increase. Concurrent sweep starts immediately after astop-the-world (STW) collection, and must at least complete a certain subset of itswork before concurrent mark is allowed to kick off, because the mark map usedfor concurrent mark is also used for sweeping, as described previously.

The concurrent sweep process is split into two types of operations:v Sweep analysis, which processes sections of data in the mark map anddetermines ranges of free or potentially free memory to be added to the free list

v Connection, which takes analyzed sections of the heap and connects them intothe free list

Heap sections are calculated in the same way as for parallel bitwise sweep.

An STW collection initially performs a minimal sweep operation that searches forand finds a free entry large enough to satisfy the current allocation failure. Theremaining unprocessed portion of the heap and mark map are left to concurrentsweep to be both analyzed and connected. This work is accomplished by Javathreads through the allocation process. For a successful allocation, an amount ofheap relative to the size of the allocation is analyzed, and is performed outside theallocation lock. In an allocation, if the current free list cannot satisfy the request,sections of analyzed heap are found and connected into the free list. If sectionsexist but are not analyzed, the allocating thread must also analyze them beforeconnecting.

Because the sweep is incomplete at the end of the STW collection, the amount offree memory reported (through verbose GC or the API) is an estimate based onpast heap occupancy and the ratio of unprocessed heap size against total heap size.In addition, the mechanics of compaction require that a sweep be completed before


a compaction can occur. Consequently, an STW collection that compacts will nothave concurrent sweep active during the next round of execution.

To enable concurrent sweep, use the -Xgcpolicy: parameter optavgpause. It isactive in conjunction with concurrent mark. The modes optthruput, gencon, andsubpool do not support concurrent sweep.

Compaction phaseWhen the garbage has been removed from the heap, the Garbage Collector canconsider compacting the resulting set of objects to remove the spaces that arebetween them. The process of compaction is complicated because, if any object ismoved, the Garbage Collector must change all the references that exist to it. Thedefault is not to compact.

The following analogy might help you understand the compaction process. Thinkof the heap as a warehouse that is partly full of pieces of furniture of differentsizes. The free space is the gaps between the furniture. The free list contains onlygaps that are above a particular size. Compaction pushes everything in onedirection and closes all the gaps. It starts with the object that is closest to the wall,and puts that object against the wall. Then it takes the second object in line andputs that against the first. Then it takes the third and puts it against the second,and so on. At the end, all the furniture is at one end of the warehouse and all thefree space is at the other.

To keep compaction times to a minimum, the helper threads are used again.

Compaction occurs if any one of the following is true and -Xnocompactgc has notbeen specified:v -Xcompactgc has been specified.v Following the sweep phase, not enough free space is available to satisfy theallocation request.

v A System.gc() has been requested and the last allocation failure garbagecollection did not compact or -Xcompactexplicitgc has been specified.

v At least half the previously available memory has been consumed by TLHallocations (ensuring an accurate sample) and the average TLH size falls below1024 bytes

v The scavenger is enabled, and the largest object that the scavenger failed totenure in the most recent scavenge is larger than the largest free entry in tenuredspace.

v The heap is fully expanded and less than 4% of old space is free.v Less than 128 KB of the heap is free.

Subpool (AIX, Linux PPC and zSeries, z/OS and i5/OS only)Subpool is an improved GC policy for object allocation that is specifically targetedat improving the performance of object allocation on SMP systems with 16 or moreprocessors. You start it with the -Xgcpolicy:subpool command-line option.

The subpool algorithm uses multiple free lists rather than the single free list usedby optavgpause and optthruput. It tries to predict the size of future allocationrequests based on earlier allocation requests. It recreates free lists at the end ofeach GC based on these predictions. While allocating objects on the heap, freechunks are chosen using a best fit method, as against the first fit method usedin other algorithms. It also tries to minimize the amount of time for which a lock is


held on the Java heap, thus reducing contention among allocator threads.Concurrent mark is disabled when subpool policy is used. Also, subpool policyuses a new algorithm for managing the Large Object Area (LOA). Hence, thesubpool option might provide additional throughput optimization for someapplications.

Reference objectsWhen a reference object is created, it is added to a list of reference objects of thesame type. The referent is the object to which the reference object points. Instancesof SoftReference, WeakReference, and PhantomReference are created by the userand cannot be changed; they cannot be made to refer to objects other than theobject that they referenced on creation. Objects with a class that defines a finalizemethod result in a pointer to that object being placed on a list of objects thatrequire finalization.

During garbage collection, immediately following the mark phase, these lists areprocessed in a specific order:1. Soft2. Weak3. Final4. Phantom

Soft, weak, and phantom reference processingThe Garbage Collector determines if a reference object is a candidate for collectionand, if so, performs a collection process that differs for each reference type. Softreferences are collected if their referent is not marked and if #get() has not beencalled on the reference object in the previous 32 garbage collection cycles. Weakand phantom references are always collected if their referent is not marked.

For each element on a list, GC determines if the reference object is eligible forprocessing and then if it is eligible for collection.

An element is eligible for processing if it is marked and has a non-null referentfield. If this is not the case, the reference object is removed from the reference list,resulting in it being freed during the sweep phase.

If an element is determined to be eligible for processing, GC must determine if it iseligible for collection. The first criterion here is simple. Is the referent marked? If itis marked, the reference object is not eligible for collection and GC moves onto thenext element of the list.

If the referent is not marked, GC has a candidate for collection. At this point theprocess differs for each reference type. Soft references are collected if their referenthas not been marked for the previous 32 garbage collection cycles. You adjust thefrequency of collection with the -Xsoftrefthreshold option. If there is a shortage ofavailable storage, all soft references are cleared. All soft references are guaranteedto have been cleared before the OutOfMemoryError is thrown.

Weak and phantom references are always collected if their referent is not marked.When a phantom reference is processed, its referent is marked so it will persistuntil the following garbage collection cycle or until the phantom reference isprocessed if it is associated with a reference queue. When it is determined that areference is eligible for collection, it is either queued to its associated referencequeue or removed from the reference list.


Final reference processingThe processing of objects that require finalization is more straightforward.1. The list of objects is processed. Any element that is not marked is processed by:

a. Marking and tracing the objectb. Creating an entry on the finalizable object list for the object

2. The GC removes the element from the unfinalized object list.3. The final method for the object is run at an undetermined point in the future

by the reference handler thread.

JNI weak referenceJNI weak references provide the same capability as that of WeakReference objects,but the processing is very different. A JNI routine can create a JNI Weak referenceto an object and later delete that reference. The Garbage Collector clears any weakreference where the referent is unmarked, but no equivalent of the queuingmechanism exists.

Note that failure to delete a JNI Weak reference causes a memory leak in the tableand performance problems. This also applies to JNI global references. Theprocessing of JNI weak references is handled last in the reference handling process.The result is that a JNI weak reference can exist for an object that has already beenfinalized and had a phantom reference queued and processed.

Heap expansionHeap expansion occurs after garbage collection while exclusive access of the virtualmachine is still held. The heap is expanded in a set of specific situations.

The active part of the heap is expanded up to the maximum if one of the followingis true:v The Garbage Collector did not free enough storage to satisfy the allocationrequest.

v Free space is less than the minimum free space, which you can set by using the-Xminf parameter. The default is 30%.

v More than the maximum time threshold is being spent in garbage collection, setusing the -Xmaxt parameter. The default is 13%.

The amount to expand the heap is calculated as follows:v If the heap is being expanded because less than -Xminf (default 30%) free spaceis available, the Garbage Collector calculates how much the heap needs toexpand to get -Xminf free space.If this is greater than the maximum expansion amount, which you can set withthe -Xmaxe parameter (default of 0, which means no maximum expansion), thecalculation is reduced to -Xmaxe.If this is less than the minimum expansion amount, which you can set with the-Xmine parameter (default of 1 MB), it is increased to -Xmine.

v If the heap is expanding and the JVM is spending more than the maximum timethreshold, the Garbage Collector calculates how much expansion is needed toexpand the heap by 17% free space. This is adjusted as above, depending on-Xmaxe and -Xmine.

v Finally, the Garbage Collector ensures that the heap is expanded by at least theallocation request if garbage collection did not free enough storage.


All calculated expansion amounts are rounded up to a 512-byte boundary on 32-bitJVMs or a 1024-byte boundary on 64-bit JVMs.

Heap shrinkageHeap shrinkage occurs after garbage collection while exclusive access of the virtualmachine is still held. Shrinkage does not occur in a set of specific situations. Also,there is a situation where a compaction occurs before the shrink.

Shrinkage does not occur if any of the following are true:v The Garbage Collector did not free enough space to satisfy the allocationrequest.

v The maximum free space, which can be set by the -Xmaxf parameter (default is60%), is set to 100%.

v The heap has been expanded in the last three garbage collections.v This is a System.gc() and the amount of free space at the beginning of thegarbage collection was less than -Xminf (default is 30%) of the live part of theheap.

v If none of the above is true and more than -Xmaxf free space exists, the GarbageCollector must calculate how much to shrink the heap to get it to -Xmaxf freespace, without going below the initial (-Xms) value. This figure is roundeddown to a 512-byte boundary on 32-bit JVMs or a 1024-byte boundary on 64-bitJVMs.

A compaction occurs before the shrink if all the following are true:v A compaction was not done on this garbage collection cycle.v No free chunk is at the end of the heap, or the size of the free chunk that is atthe end of the heap is less than 10% of the required shrinkage amount.

v The Garbage Collector did not shrink and compact on the last garbage collectioncycle.

On initialization, the JVM allocates the whole heap in a single contiguous area ofvirtual storage. The amount that is allocated is determined by the setting of the-Xmx parameter. No virtual space from the heap is ever freed back to the nativeoperating system. When the heap shrinks, it shrinks inside the original virtualspace.

Whether any physical memory is released depends on the ability of the nativeoperating system. If it supports paging; the ability of the native operating system tocommit and decommit physical storage to the virtual storage; the GarbageCollector uses this function. In this case, physical memory can be decommitted ona heap shrinkage.

You never see the amount of virtual storage that is used by the JVM decrease. Youmight see physical memory free size increase after a heap shrinkage. The nativeoperating system determines what it does with decommitted pages.

Where paging is supported, the Garbage Collector allocates physical memory tothe initial heap to the amount that is specified by the -Xms parameter. Additionalmemory is committed as the heap grows.


Generational Concurrent Garbage CollectorThe Generational Concurrent Garbage Collector has been introduced in Java 5.0from IBM. A generational garbage collection strategy is well suited to anapplication that creates many short-lived objects, as is typical of many transactionalapplications.

You activate the Generational Concurrent Garbage Collector with the-Xgcpolicy:gencon command-line option.

The Java heap is split into two areas, a new (or nursery) area and an old (ortenured) area. Objects are created in the new area and, if they continue to bereachable for long enough