Following my previous entry on Netbeans, I should mention that I was using 5.5, the current stable release, not one of the 6.0 Milestones which are supposed to have a much improved editing environment according to comments in this session
of the Java Posse Roundup.
With regards the profiler, it was indeed much nicer than the Eclipse TPTP experience, but you need to read the fine print. I can’t say how much time I wasted trying to discover where all my heap was going before I read (my bold):
The total number of objects allocated for each class that Profiler presents (in both “Record Object Creation” and “Record Object Creation and Garbage Collection” modes) is exact, whereas other numbers (such as total object size) and the reverse call graphs are by default obtained statistically.
Ultimately, using a combination of the netbeans profiler, jmap -histo, and the profiler’s ability to record the stack when allocations happen proved to be the most useful approach. The instant illumination of seeing that it’s your Map implementation that’s responsible for all the space, then looking at the allocation stack traces and discovering that it’s actually one particular use of the Map that’s the problem.
Post a Comment
You must be logged in to post a comment.