java garbage collection, monitoring, and tuning
TRANSCRIPT
- 1. JavaGarbage Collection
- Carol McDonald
-
- Java Architect
-
-
- Sun Microsystems, Inc.
-
2. Speaker
- CarolcDonald:
-
- Java Architect at Sun Microsystems
-
- Before Sun, worked on software development of:
-
-
- Application tomanage LoansforBig Banks(>10 million loans)
-
-
-
- PharmaceuticalIntranet( RocheSwitzerland)
-
-
-
- TelecomNetwork Mgmt( DigitalFrance)
-
-
-
- X.400Email Server( IBMGermany)
-
3. GarbageCollection 4. Classic Memory Leak inC
- User does the memory management
- void service(int n, char** names) {
- for (int i = 0; i < n; i++) {
-
- char* buf = (char*)malloc (strlen(names[i]));
-
- strncpy(buf, names[i], strlen(names[i]));
- }
- // memory leaked here
- }
- User is responsible for callingfree()
- User is vulnerable todangling pointers and double frees.
5. Garbage Collection
- Find and reclaimunreachableobjects
-
- not reachable from the applicationroots:
-
-
- (thread stacks, static fields, registers.)
-
-
- Traces theheapstarting at theroots
-
-
- Visits every live object
-
-
- Anything not visited isunreachable
-
-
- Therefore garbage
-
- Variety of approaches
-
- Algorithms: copying, mark-sweep, mark-compact, etc.
6. Garbage Collection
- Garbage collection:Pros
-
- Increased reliability no memory leaks, no dangling pointers
-
-
- Eliminatesentire classes of(Pointer) bugs ,no segmentation fault, no double frees
-
-
-
- Improved developer productivity
-
-
- Truememory leaksare not possible
-
-
- possible for an object to be reachablebutnotusedby the program
-
-
-
- unintentional object retention ,Can cause OutOfMemoryError
-
-
-
- Happens less often than in C, and easier to track down
-
- Cons
-
- Pauses
7. Statistics
- Most objects are very short lived
-
- 80-98%
- Old objects tend to live a long time
-
- avoid marking and sweeping the old
8. Generational Garbage Collection
- Keep young and old objects separate
-
- In spaces calledgenerations
- Different GC algorithmsfor each generation
-
- Use the right tool for the job
9. How Generational GC Works 10. Incremental Garbage Collection
- Minor Garbage Collection(scavenge)
-
- When eden is full a minor gc is invoked
-
- Sweeps through eden and the current survivor space, removing the dead and moving the living to survivor space or old
-
- Ss0 and ss1 switch which is current A new tenuring age is calculated
- Major Garbage Collection
-
- When old is full
-
- All spaces are garbage collected including perm space
-
- All other activities in the jvm are suspended
11. New Old Space Tuning
- 25-40% should be new space
- how much new space depends on App:
-
- Stateless Request centric Application with high morbidity rate needs more new space for scalability
-
- Stateful Workflow Application with more older objects needs more old space
12. Garbage Collection
- Mythsaboutgarbage collectionabound
-
- Myth: Allocation and garbage collectionare slow
-
-
- InJDK1.0 , they were slow (as was everything else)
-
-
-
- Memory management (allocation + collection) in Java is often significantly faster than in C
-
-
-
-
- Cost of new Object() is typically ten machine instructions
-
-
-
-
-
- It's just easier to see the collection cost because it happens all in one place
-
-
- Early performance advice suggestedavoiding allocation
-
- Bad idea!
-
- Alternatives (likeobject pooling ) are oftenslower , moreerror prone , andless memory-efficient
13. Object Allocation (1/2)
- Typically, object allocation isvery cheap!
-
- 10 native instructions in the fast common case
-
- C/C++ has faster allocation? No!
- Reclamation ofnew objectsis very cheap too!
-
- Young GCsingenerationa l systems
- So
-
- Do not be afraid to allocatesmall objects for intermediate results
-
- Generational GCslovesmall, short-lived objects
14. Object Allocation (2/2)
- Wedo notadvise
-
- Needlessallocation
-
-
- More frequent allocations will cause more frequent GCs
-
- Wedoadvise
-
- Using short-lived immutable objects instead of long-lived mutable objects
-
- Usingclearer,simplercodewithmore allocationsinstead of moreobscurecode with fewerallocations
15. Large Objects
- Verylargeobjects are:
-
- Expensive toallocate(maybe not through the fast path)
-
- Expensive toinitialize(zeroing)
-
- Can causeperformanceissues
- Large objects of different sizes can causefragmentation
-
- For non-compacting or partially-compacting GCs
- Avoidif you can
-
- And, yes, this is not always possible or desirable
16. Object Pooling (1)
- Legacy of older VMs with terrible allocation performance
- Remember
-
- Generational GCs loveshort-lived, immutable objects
- Unused objects in pools
-
- Are like abadtax, the GC must process them
-
- Safety
-
-
- Reintroducemalloc/free mistakes
-
-
- Scalability
-
-
- Must allocate/de-allocate efficiently
-
-
-
- synchronizeddefeats theVMsfast allocation mechanism
-
17. Object Pooling (3/3)
- Exceptions
-
- Objects that areexpensivetoallocateand/orinitialize
-
- Objects that represent scarceresources
-
- Examples
-
-
- Threads pools
-
-
-
- Database connectionpools
-
-
- Use existing libraries wherever possible
18. Memory Leaks?
- But, the GC is supposed to fix memory leaks!
- The GC will collect allunreachableobjects
- But, it will not collect objects that arestillreachable
- Memory leaks in garbage collected heaps
-
- Objects that arereachablebutunused
-
- Unintentional object retention
19. Memory Leak Types
- Traditional memory leaks
-
- Heap keepsgrowing , andgrowing,andgrowing
-
- OutOfMemoryError
- Temporary memory leaks
-
- Heap usage istemporarilyveryhigh , then itdecreases
-
- Bursts offrequent GCs
20. Memory Leak Sources
- Objects in the wrong scope
- Lapsed listeners
- Exceptions change control flow
- Instances of inner classes
- Metadata mismanagement
- Use of finalizers/reference objects
21. Objects in the Wrong Scope (1/2)
- Below, names really local to doIt()
-
- It will not be reclaimed while the instance of Foo is live
- class Foo {
- private String[]names ;
- public voiddoIt (int length) {
- if (names == null || names.length < length)
- names = new String[length];
- populate(names);
- print(names);
- }
- }
22. Objects in the Wrong Scope (2/2)
- Remember
-
- Generational GCs love short-lived objects
- class Foo {
- public void doIt(int length) {
- String[] names = new String[length];
- populate(names);
- print(names);
- }
- }
23. Memory Leak Sources
- Objects in the wrong scope
- Lapsed listeners
- Exceptions change control flow
- Instances of inner classes
- Metadata mismanagement
- Use of finalizers/reference objects
24. Exceptions Change Control Flow(1/2)
- Beware
-
- Thrown exceptions can change control flow
- try {
- ImageReader reader = new ImageReader();
- cancelButton.addActionListener(reader);
- reader.readImage(inputFile);
- cancelButton.removeActionListener(reader);
- } catch (IOException e) {
- // if thrown from readImage(), reader will not
- // be removed from cancelButton's listener set
- }
25. Exceptions Change Control Flow(2/2)
- Always use finallyblocks
- ImageReader reader = new ImageReader();
- cancelButton.addActionListener(reader);
- try {
- reader.readImage(inputFile);
- } catch (IOException e) {
- ...
- }finally {
- cancelButton.removeActionListener(reader);
- }
26. Memory Leak Sources
- Objects in the wrong scope
- Lapsed listeners
- Exceptions change control flow
- Instances of inner classes
- Metadata mismanagement
- Use of finalizers/reference objects
27. Metadata Mismanagement (1/2)
- Sometimes, we want to:
-
- Keep track of object metadata
-
- In a separate map
- class ImageManager {
- private Map map =
- new HashMap();
- public void add(Image image, File file) { ... }
- public void remove(Image image) { ... }
- Public File get(Image image) { ... }
- }
28. Metadata Mismanagement (2/2)
- What happens if weforgetto callremove (image)?
-
- never be removed from the map
-
- Verycommonsource ofmemory leaks
- We want:
-
- purge the corresponding entry when the key is not reachable
- Thatsexactlywhat a WeakHashMap does
-
- purge the corresponding entry
- private Map map =
- newWeak HashMap();
29. Some Memory Management Myths
- Myth: Explicitlynulling referenceshelps GC
-
- Rarely helpful
-
-
- Unless you are managing your own memory
-
-
- Can beharmfulto correctness or performance
- Myth: CallingSystem.gc()helps GC
-
- Triggers full collection less efficient
-
- Can be a huge performance loss
- Myth:Avoid object allocation
-
- Allocationin Java is lightningfast
-
-
- Avoidance techniques (e.g.,pooling ) are verytrickyto get right
-
30. Local Variable Nulling
- Local variable nulling i s n ot necessary
-
- The JIT can do liveness analysis
- void foo() {
- int[] array = new int[1024];
- populate(array);
- print(array);// last use of array in method foo()
- array = null;// unnecessary!
- // array is no longer considered live by the GC
- ...
- }
31. Some Memory Management Myths
- Myth: Finalizers are Java's idea of destructors
-
- Finalizers are rarely neededand very hard to use correctly!
-
-
- Should only be used for native resources
-
-
-
- Addssignificant work to GC , hassignificant performanceeffect
-
-
- Instead, use finally blocks to release resources
- Resource r = acquireResource();
- try {
- useResource(r); } finally {
- releaseResource(r);
- }
-
-
- Note resource acquisition is outside the try block
-
-
-
- Use forfile handles, database connections,etc
-
32. Virtual Machine Smart Tuning 33. How Smart Tuning Works
- Providegood out of the box performancewithouthandtuning
- Determine type of machineJVM is running onconfigure Hotspotappropriately
- Servermachine
-
- Larger heap, parallel garbage collector , and server compiler
- Clientmachine
-
- Same as 1.4.2 ( small heap ,serial garbagecollector, and client compiler
34. Smart Tuning
- Dynamically adjustJava HotSpot VM software environment atruntime
- Adaptive Heap Sizing policy
- Simple tuning optionsbased on application requirements not JVM internals
35. Effects of Tuning Tuned vs. Non-tuned JVM 36. Hand Tuned vs. Smart Tuning 37. Monitoring & Management 38. Memory Leak Detection Tools
- Many tools to choose from
- Is there a memory leak?
-
- MonitorVMs heapusage withjconsoleandjstat
- Which objects are filling up the heap?
-
- Get a class histogram with jmapor
-
- -XX:+PrintClassHistogram and Ctrl-Break
- Why are these objects still reachable?
-
- Getreachabilityanalysis withjhat
39. Monitoring, Management, Diagnostics
- GUI tools: JConsole, jhat, VisualGC (NetBeans), dynamic attach
- Command line tools: jps, jstat, jstack, jmap, jinfo
- Diagnostics: CTRL-Break handler, heap dump, better OutOfMemoryError and fatal error handling, JNI crashes
- Tracing/logging: VM tracing and HotSpot probes, DTrace integration
http://blogs.sun.com/roller/page/dannycoward/20060310 40. Monitoring and Management
- Attach on demand for
-
- jconsole : can connect to applications that did not start up with the JMX agent
-
- jstack : takes a 'photograph' of all the threads and what they are up to in their own stack frames
-
- jmap : takes a detailed 'photograph' of what's going on in memory at any one point in time
-
- jhat : forensic expert that will help you interpret the result of jmap
41. Jconsole http://www.netbeans.org/kb/articles/jmx-getstart.html 42. NetBeans Profiler
- Low overhead profiling
- Attach to running applications
- CPUperformance profiling
- Memoryprofiling
- Memory leakdebugging
- Task based profiling
- Processing collected data offline
- http://www.netbeans.org/kb/55/profiler-tutorial.html
43. NetBeans Profiler 44. Demo http://www.javapassion.com/handsonlabs/5116_nbprofilermemory.zip Memory leak detection with Netbeans Profiler 45. VisualVM
- A new Integrated and Extensible Troubleshooting Tool for the Java Platform
- Integrates existing JDK Management, Monitoring and Troubleshooting tools and adds support for lightweight CPU and Memory profiling
- Extensible through VisualVM Plugins Center
- Production and development time tool
- Audience: developers, administrators, performance and sustaining engineers, etc.
- https://visualvm.dev.java.net
46. VisualVM Features (1/3)
- Monitor local & remote Java applications
- Show configuration & environment
- Monitor performance, memory, classes...
47. VisualVM Features (2/3)
- Monitor threads
- Profile performance & memory
- Take & display thread dumps
48. VisualVM Features (3/3)
- Take & browse/analyze heap dumps
- Analyze core dumps
- Take & display application snapshots
49. Plugins
- Sampler
- MBeans Browser
- Visual GC
- BTrace
- Buffer Monitor
- ME Snapshot Viewer
- GlassFish (+GFPM)
- OQL Editor
- TDA Plugin (3 rdp.)
- OSGi Plugin (3 rdp.)
- Message Queue (GF)
- Sun Grid Engine Inspect
- https://visualvm.dev.java.net/plugins.html
50. Resources and Summary 51. For More Information (1/2)
- Memory management white paper
-
- http://java.sun.com/j2se/reference/whitepapers/
- Destructors, Finalizers, and Synchronization
-
- http://portal.acm.org/citation.cfm?id=604153
- Memory-retention due to finalization article
-
- http://www.devx.com/Java/Article/30192
52. For More Information (2/2)
- FindBugs
-
- http://findbugs.sourceforge.net
- Heap analysis tools
-
- Monitoring and Management
-
-
- http://java.sun.com/developer/technicalArticles/J2SE/monitoring/
-
-
- Troubleshooting guide
-
-
- http://java.sun.com/javase/6/webnotes/trouble/
-
-
- JConsole
-
-
- http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
-
53. Resources
- Performance, Monitoring and Management, Testing, and Debugging of Java Applications
-
- http://www.javapassion.com/javaperformance/
-
- http://netbeans.org/kb/docs/java/profiler-intro.html
-
- http://www.netbeans.org/community/magazine/html/04/profiler.html
54. Resources
- Performance, Monitoring and Management, Testing, and Debugging of Java Applications
- Monitoring and Management in 6.0
-
- http://java.sun.com/developer/technicalArticles/J2SE/monitoring/
- Troubleshooting guide
-
- http://java.sun.com/javase/6/webnotes/trouble/
- JConsole
-
- http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
55. Stay in Touch with Java SE
- http://java.sun.com/javase
- JDK 6
-
- http://jdk6.dev.java.net/
-
- http://jcp.org/en/jsr/detail?id=270
- JDK 7
-
- http://jdk7.dev.java.net/
-
- http://jcp.org/en/jsr/detail?id=277
56. Thank You!
- Carol McDonald
-
- Java Technology Architect
-
-
- Sun Microsystems, Inc.
-