« JavaFX Breakout (Project Nile) Webstart Link
Groovy Java SE Project Postmortem »

Leaking Memory? Try Netbeans 6.5 (Beta)

Sunday, October 12th, 2008

For the past ten months I’ve been working on a Java desktop application for Chicago’s budget office that essentially loads up the city’s seven billion dollar budget and format it into a nice 600+ page public document. Multiple copies of these 600 page “budget book drafts” can exist at once, and be loaded into the application at will.

But the application had a problem. It didn’t take long before loading multiple copies of the same multi-billion dollar budget reintroduced me to my old friend java.lang.OutOfMemoryError.  OutOfMemoryError and I go way back, having worked with more memory constrained devices such as the Handspring Visor and the eTextbook reader, goReader – the latter was a C++ job and at least at the decency to crash the entire device if I failed to release memory.

So I had a memory leak.  I could take the easy way and require that the users allocate 256MB to the heap, or I could roll up my sleeves and track down that pesky leak.

I took the easy way, of course.

But then a few months later I read Tor Norbye’s excellent blog post on NetBeans profiling.

Now I had originally started developing this project on Netbeans (6.0? 6.1 beta?) back in January when I started it, but abandoned it when I started using Groovy in favor of an IDE with a workable Groovy plugin.

But after reading Tor’s account of tracking down a memory leak, and seeing the screen shots, my heart went out to Netbeans once again, and I downloaded version 6.5 (beta).

Now, I know that the profiler has been integrated into Netbeans for a while, so I don’t know if any of the features are specific to 6.5 (beta) or how far back they go.  Regardless though, having a profiler integrated right into the IDE is most certainly the way to go.

My previous profiling excursions had been limited to JProbe.  JProbe with it’s complicated licensing (if I worked from home I couldn’t run the profiler — “per CPU” might as well be called “Completely Inflexible”) and high time investment even to get the application running, made profiling an unhappy experience.

Profiling in Netbeans, on the other hand, was extremely intuitive and surprisingly responsive (Profiling is typically slow work, at least for me).

The “Find Nearest GC Root” option takes much of the guesswork out of who’s holding which reference. Finding my memory leak really did turn out to be as easy as starting the profiler, taking a snapshot of the heap, finding a reference that shouldn’t have been there (but was), and navigating back to the GC root.  Awesome.

Incidentally, the groovy support in 6.5 is much improved, and I hesitate to say it, but I think may have surpassed Eclipse’s current offering.  I also noticed an improved Error Console (very similar to Eclipse) that, if it was there before, I couldn’t for the life of me find out where.

Now that my current project is wrapping up, I think that Netbeans will be at the top of my IDE list at the start of my next one. Version 6+ of Netbeans has really turned this IDE around.

Tags:

This entry was posted on Sunday, October 12th, 2008 at 10:06 pm and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply