| By Calvin Austin | Article Rating: |
|
| October 12, 2005 07:45 AM EDT | Reads: |
29,770 |
Many years ago I saved up for a 16K RAM pack for my tiny Sinclair ZX81 computer. I thought, rather naively, that this was going to be the answer to all my memory issues. I would be able to use increasingly complex programs, okay games, and I could program without the restriction of literally making every byte count. I quickly found out, as you have already discovered if you have been writing Java applications for a while, that adding more memory to your machine is not always the answer to the running out-of-memory problem, the infamous "OutofMemoryError". Dr. Phil, a TV psychologist, likes to use the quote, "You can't solve money problems with money." I believe the same thing applies to the JVM, "You can't always solve memory problems, with more memory." Treating just the symptom doesn't have a long-lasting effect.
So why, when Java was going to save us all from thinking about memory allocation, do we now have to think about memory allocation? If you look around, it's obviously a common issue, and there is no shortage of profiling and diagnostic tools. Carlos E. Perez covers a long list of tools in his manageability blog: www.manageability.org/blog/stuff/open-source-profilers-for-java/view and that's not even the full list Java developers have at hand.
Go to any Java conference and you are bound to hear at least one presentation about out-of-memory errors. There were some good sessions at this year's JavaOne. One was a packed BOF led by some of my old colleagues from the Sun serviceability team discussing the six ways to meet an out-of-memory error and another from Steffan and the JRockit JVM team at BEA.
Memory Leaks in Production
The challenge has always been to provide a memory leak tool that your IT staff will let you try in production. Realistically, many slow memory leaks only occur at deployment time, partly due to the changed environment and partly due to the longer uptime of the application. In many cases an IDE-based tool may not be convenient in those scenarios; the other catch is that you also want the diagnostics to have a minimal affect on the application itself. So recompiling to add profiling hooks is often really only the last resort, if at all. To help ease this barrier to adoption, JDK 5.0 included byte code insertion, this technology has been used by profiling tools to do this 're-compilation' at runtime to make this more palatable One thing that you may not be aware of is that the Sun JVM automatically generates some very lightweight counters, available by default in 1.4.2. Sun JVM tools such as jmap and visualgc can provide a view into the garbage collectors operation. The jconsole demo in JDK 5.0 also provides some insight into the garbage collector providing you started the JVM with the option -Dcom.sun.management.jmxremote.
There is also an improved hprof profile agent in JDK 5.0 that can be used to dump out profiling information in a format that can be used by the hat analysis tool from java.net. I find it more useful for snapshotting a JVM, than letting it run to completion. To generate a hprof file I can use QUIT signal, kill -3 on Unix after starting the JVM with the hprof agent -agentlib:hprof=heap=all,format=b. The hat tool looks for the java.hprof output file by default and starts a mini Web server at port 7000. This allows you to browse the object instances used by the JVM. It's by no means as powerful as the commercial tools, but can give you some clues as to what is going on.
Who Has My Memory?
Everyone generally has the same advice about memory leaks in Java. Providing you have already sized your maximum heap correctly (if heap is the detected out-of-memory condition), e.g., -Xmx512m, then some number of objects is holding onto references to other objects that are no longer required. As these objects are still reachable, and hence live, they will not be marked by the garbage collector as objects that can be deleted.
One of the classic examples given is that you wrote some JNI code and forgot to free the memory. Now, admittedly, that's fairly easy to do if you are using JNI, but what if your application has no JNI code at all?
First, rule out your code or dependent libraries or even the JVM. It's less common than it used to be, but JVMs do still have bugs. One area to check is if there are exceptions at deployment time. Sometimes the unsuccessful code paths are not as diligent at cleaning up non-local instances as the successful code path. Even a simple operation, such as creating a substring from a string, and some StringBuffer operations have caused leaks in a few of the 1.4 releases.
Dependent libraries could be an XML parser or JDBC driver. Both need to frequently build, manipulate, and copy chunks of data. Try using an alternative release number or version of both. Again it may not be your code at fault. If you still strongly suspect you've introduced the leak, what should you look at? Caches are prime suspects, or any place where you store references, whether it's a vector, array or Collection can easily always hang on to reachable objects. Make sure you null the references or use weak references. Other areas to check are custom classloaders if you use them. By their very nature they hold on to many references, and if you're using finalizers. remember they may never get called.
Now that desktop machines have 1Gb of memory installed instead of 1K, it's still necessary to watch your bytes. Tracking down a memory leak is never easy, however, there are certainly more tools and techniques at your disposal than ever before.
Published October 12, 2005 Reads 29,770
Copyright © 2005 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Calvin Austin
A section editor of JDJ since June 2004, Calvin Austin is an engineer at SpikeSource.com. He previously led the J2SE 5.0 release at Sun Microsystems and also led Sun's Java on Linux port.
![]() |
SYS-CON En Espanol 10/12/05 07:00:34 AM EDT | |||
Help I'm Out Of Memory! Who Has My Memory? |
||||
![]() |
JDJ News Desk 10/11/05 03:37:47 PM EDT | |||
Java Developer's Journal Editorial - Who Has My Memory? Many years ago I saved up for a 16K RAM pack for my tiny Sinclair ZX81 computer. I thought, rather naively, that this was going to be the answer to all my memory issues. I would be able to use increasingly complex programs, okay games, and I could program without the restriction of literally making every byte count. I quickly found out, as you have already discovered if you have been writing Java applications for a while, that adding more memory to your machine is not always the answer to the running out-of-memory problem, the infamous 'OutofMemoryError'. |
||||
![]() |
Gordon Harding 09/30/05 09:16:41 AM EDT | |||
Any suggestions on how to determine if JNI is the issue on out of memory prolems. We have deployed using JVM 1.4.2 and another group has included a COM object using JNI. I would like to lay at their feet but lack the tools to do so. |
||||
![]() |
Gordon Harding 09/30/05 09:16:31 AM EDT | |||
Any suggestions on how to determine if JNI is the issue on out of memory prolems. We have deployed using JVM 1.4.2 and another group has included a COM object using JNI. I would like to lay at their feet but lack the tools to do so. |
||||
![]() |
Gordon Harding 09/30/05 09:16:19 AM EDT | |||
Any suggestions on how to determine if JNI is the issue on out of memory prolems. We have deployed using JVM 1.4.2 and another group has included a COM object using JNI. I would like to lay at their feet but lack the tools to do so. |
||||
- It's the Java vs. C++ Shootout Revisited!
- Patterns for Building High Performance Applications
- Asynchronous Logging Using Spring
- Java for Programmers (2nd Edition)
- Cross-Platform Mobile Website Development – a Tool Comparison
- Three Buzzwords That Every CIO Hears but One They Should Listen To
- Write Once Run Anywhere or Cross Platform Mobile Development Tools
- Immersing into JavaScript Frameworks
- Workday Reportedly Prepping to Go Public
- Cloud Expo New York: The Java EE 7 Platform - Developing for the Cloud
- Book Review: Sams Teach Yourself Java in 24 Hours
- OpenOffice.com Lives
- Book Excerpt: Introducing HTML5
- Adobe Sends Flex to the Apache Foundation
- Five Years Waiting for JRE 7: Is It Justified? (Part 1)
- Book Excerpt: Java Application Profiling Tips and Tricks
- i-Technology in 2012: Five Industry Predictions
- It's the Java vs. C++ Shootout Revisited!
- Patterns for Building High Performance Applications
- OpenXava 4.3: Rapid Java Web Development
- The Next Web Architecture
- Asynchronous Logging Using Spring
- Java for Programmers (2nd Edition)
- Is Write Once Run Anywhere Ever Going to Be a Reality?
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- JavaServer Faces (JSF) vs Struts
- The i-Technology Right Stuff
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate
- Why Do 'Cool Kids' Choose Ruby or PHP to Build Websites Instead of Java?
- What's New in Eclipse?
- i-Technology Predictions for 2007: Where's It All Headed?



















