Dave Landers

The last few months, I have been working on a performance project for WebLogic Portal 10.2.

It started as a project to increase performance, but we quickly determined that there was a larger roadblock that had to be cleared first. Over the last couple of releases, we have let more memory leaks back into the product. We had worked really hard to clear these out a while ago, but did not follow up with testing - so we left the door open and more leaks got in.

We have now cleared all the leaks we have found, and are in process of establishing a test environment to keep them from coming back.

These leaks have some characteristics that I found interesting:

• The leaks we were targeting happen upon redeploy of an application.
• They result from (unintentional) retained references to the application’s ClassLoader.
• Since hotspot holds classes in a fixed-size Permanent Generation, the leaks eventually (after a few redeploys) result in a serious and unrecoverable JVM failure.
• The leaks are surprisingly easy to trigger, with innocent-looking code.

The good news for most J2EE developers is that these leaks are generally not possible for an application to trigger (assuming you follow good J2EE coding practices). We (WLS and WLP) see them because we implement services that live in the system classpath (rather than in the application’s ClassLoader).

Over the next several posts, I’ll outline some of my findings and some tips for hunting such leaks.

Technorati Tags: memory, portal, WebLogic