Skip to Content
In my last blog about the JavaOne 2007 I touched briefly upon our tool for Java heap dump analysis which we have developed in our department, the SAP Memory Analyzer. But why had SAP as a business software company to write such a developer tool and wasn’t just using the other available tools on the market? Well, we couldn’t.

SAP has “some” Java development going on, I think more than 1500 Java guys alone in my board area, with millions lines of code and hundreds of thousands of classes. Our customers put even more on top of it and being part of the team building the Java Application Server we were confronted with all kinds of general problems, among them the OutOfMemoryError. But the problem was, nobody knew exactly what went wrong just by looking at the Java Error alone as this type of problem can happen anytime and anywhere. However, our customers naturally wanted answers why they got one and they wanted to know if they or SAP caused the problem, i.e. we needed to provide answers, but this is difficult if you only have the Error, and it is especially difficult if it happens on productive systems which you have no access to.

So we asked Sun to dump the heap when an OutOfMemoryError happens and back-port this feature to older Sun HotSpot VM releases. Heap dumps basically contain all Java Objects and their references and there are already some tools available for their analysis. I don’t want to blame anyone – there are really good profiler tools out there –, but those tools had their difficulties on this kind of “enterprise-scale” memory problems and heap dumps. If you know where to look, because you know the crashed application by heart, you can solve the problem by heap walking, but the poor guy in support who hasn’t written any line of code can’t do that. Plus, the tools available consume a lot of resources – those of you who have tried to open and analyze a 500 MB or even multi-GB heap dump will know – you need lots of time and a much bigger box for analysis than for production. Now the production machines of our customers are already pretty big, so you can image.

That’s why we couldn’t use the available tools. They were not fast enough, used too much memory and if you don’t know the crashed piece of Software, you couldn’t understand what went wrong just by heap walking. Take for example heap dumps with millions of Strings in them. Walking them one by one won’t help you much – you need to find the aggragation patterns. I don’t like those product demos very much where they show you a problem in your own class appearing in a class histogram right on top. That’s just not reality. Some more supporting approaches in memory analysis techniques were needed and that’s why we had to make our own tool, which is luckily helpful to all Java developers.

Meanwhile the tool is free for download on our Wiki. If you like, have a look.
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply