Eye on Performance: Profiling on the Edge
By Jack Shirazi & Kirk Pepperdine2005-04-21
Back to the Beginning
|
|
We started with those that seemed targeted at memory analysis. Open source memory profiler number one seemed to be utterly simple -- almost too simple. The output would be of very limited use, only a list of classes and counts of objects by class. But that was as good as anywhere to start. It crashed. We had that sinking feeling that we were headed down the same path as before. Open source profiler number two was even simpler than number one, though it actually gave more detailed information -- a heap dump with one entry per object, showing each object's size and class. Like the other profilers, we tried it out at lower scales, and we could see the heap dump was going to be big -- roughly the size of the heap, so we were looking at a 1 GB output file. We tried it. It crashed the VM. But it did give us a partial dump.
When you are dealing with large factors like this, it is important to get a sense for the magnitude of the required resources and how long things are going take. To dump output to a 1 GB file could take many minutes. If you're not prepared for how long an operation is likely to take, you may mistakenly think the process is hung when in fact it is chugging along, just taking as long as is required to dump out a gigabyte of formatted text. This open source profiler was working -- but we had neglected to give it enough time in the first test. To compound the problem, we then forced it to give a second dump in the middle of the first -- which caused it to crash. Fortunately, we figured out that the problem was us, and not the profiler, and with slightly better awareness, we tried it again and it worked.
The heapprofile profiler
So, which profiler worked? It was "heapprofile" written by Matthias Ernst. It was nothing more than a page of C code using the Java Virtual Machine Profiler Interface (JVMPI) to dump the heap in the simplest format possible. You even have to compile it yourself, no pre-compiled executables are available from the Web site (see Resources). It was the level of simplicity we needed for this problem. No overhead at all. No use of heap or JNI resources beyond the absolute minimum. It did nothing while the program was running, then when I wanted a heap dump it simply walked the heap, dumping each object's size and class directly to a file -- no building up of in-memory structures, which was what made all the other profilers crash the JVM.
Of course, we weren't done yet. Now we needed to analyze the resulting data, and use it to determine what objects were being used by the application. Fortunately, the output format was easy to parse. Once we found the objects that were causing trouble, we had to find the allocation sites for those objects. To do that in a low overhead way, we used the simple tactic of recompiling those few classes with a stack tracker in the constructor, a technique detailed in Jack's book (see Resources). This simple technique involves creating -- but not throwing -- an exception in the constructor. That exception contains a stack trace for the allocation site. Then you tabulate those stacks for all the objects. Because most stacks are the same, you don't actually have to store very much data -- at most a few thousand strings -- identifying call stacks and the associated numbers of instances linked to each stack.
Tutorial Pages:
» What do you do When Your Tools are Too Fat?
» A Trip to the Fat Farm
» Back to the Beginning
» Simple But Ugly
» The Final Word
» Resources
First published by IBM developerWorks
|
