I previously mentioned a JVM flag that has the potential to really clarify things when you encounter a OutOfMemoryError in production.
When I first utilized this flag, my heap dump file was probably about 500M. It's a year later, and we just had another OutOfMemoryError (OOM). This time, the heap dump size was more like 1.1G. If you've ever struggled with Java OOMs on 32-bit Windows in the past, you know 1.1 is effectively the largest heap size you can get away with. I don't necessarily agree with -Xmx1.1G in the least, but that's a different post.
It appears that to analyze a 1.1G heap dump file, jhat requires greater than 1.1G of heap allocated for the analysis. In other words, if you max out heap on your application, you won't be able to analyze the heap dump on a similar machine. In other words, if you max out heap on a 32-bit OS, you'll need a 64-bit OS to analyze it.
I also tried SAP Memory Analyzer and YourKit on my 32-bit machine, just to see. Same experience - the OOM analysis tools crash with an OOM. Finally, I tried SAP Memory Analyzer on a 64 bit machine, and it worked well. After seeing the contents of the heap, it was very easy to diagnose the problem. I'm not sure I ever would have solved the problem w/o it.
I've since found out the YourKit 7.1 EAP can handle massive heap dumps on 32 bit machines: I was able to analyze the file by passing in -Xmx700M to YourKit. Overall, I was really impressed w/ SAP and YourKit in terms of polish and responsiveness from support.
- ▼ 2008 (7)