Conference News & Coverage
Sponsors

Diamond Sponsors

  • Fotango
  • Intel
  • Microsoft

Gold Sponsors

  • Dell Inc.
  • Hewlett Packard
  • IBM
  • Mozilla Corporation

Silver Sponsors

  • ActiveState
  • Autodesk
  • Google
  • Greenplum
  • Ingres
  • Novell, Inc.
  • NYTimes.com
  • OpSource
  • Rearden Commerce
  • SnapLogic
  • ThoughtWorks
  • Ticketmaster

Sponsors & Exhibitors

For information on exhibition and sponsorship opportunities at the convention, contact Sharon Cordesse

For Media Partnership opportunities, please contact Avila Reese

Download the OSCON Sponsor/Exhibitor Prospectus (PDF).

Conference News

To stay abreast of Conference news and to receive email notification when registration opens, please sign up here.

Press & Media

For media-related inquiries, contact Dawn Applegate at

Program Ideas

Drop us a line at and tell us who and/or what would make OSCON a must-attend event.

User Groups & Professional Associations

For user group and professional association related inquiries, contact Marsee Henon at

Session

Memory Leaks in Java Applications: Different Tools for Different Types of Leaks

Gregg Sporar, Technology Evangelist, Sun Microsystems

Track: Java
Date: Thursday, July 26
Time: 10:45am - 11:30am
Location: Portland 251

Not all memory leaks are the same. Some eat away at memory slowly over time. Others grab huge chunks of memory all at once. What is common for most of them is that they ultimately cause the virtual machine's heap to run out of space. A large variety of free and open source tools provide a high-level view of a Java application's memory usage, but not all of them are appropriate for doing the detailed analysis needed to find the cause of a memory leak. Depending on the type of memory leak, some tools are more appropriate than others. This session examines some of the tools and techniques available and uses example memory leaks from real-world Java applications.

The presentation shows how to track down a memory leak where multiple object instances of the same class are created over time, some of which are the source of a leak and others of which are not. It also examines how to debug a memory leak where only a single object instance is the source of the problem. Each of these examples involves a brief examination of the source code causing the leak and a demonstration using open source monitoring/profiling tools. Comparisons are done between the two different situations and the capabilities of the different tools.