3 ms·

A day in the life of a memory leak hunter

14 points by hollywoodcole 19y ago

cstejerean 19y ago
As a mental exercise think how many people that call themselves "Java developers" would be able to troubleshoot the issues this guy encountered. I love statements like "take a look the code below" followed by what appears to be perfectly normal code to me and then "the problem in the code above is obvious".
- bayareaguy 19y ago
  This guy definitely deserves credit for focusing on the problem. Most java developers I know would have tried some cheezy workaround like periodically restarting the process. As a consequence things like this go unsolved for years. This is actually a common issue whenever you have long-lived processes which suck in third-party code. Half the complaints I see about browsers these days is that they leak memory. I remember a similar problem in C++ years ago with a poorly coded initializer. One of the core dumps of an X application I looked into had over 50 megabytes of copies of the string "Helvetica".
asmosoinio 19y ago
I read it, understood some of it -- and am now happy not to be this guy. And I do consider myself a "Java developer", even though I have not been working with Java lately.
huherto 19y ago
Excellent article, it was invaluable to me a couple of years ago when I was trying to find a memory leak that was placing a very large project in jeopardy.
gojomo 19y ago
Though he doesn't mention which Java version he's using, nowadays some core bundled facilities can make such diagnoses a lot quicker. 'jmap -histo' give you instance counts by class in a running JVM -- so over a period of unexpected memory retention, or the period just before an OOME, you can identify supspiciously overrepresented types. A binary heap dump and then browse with the 'jhat' tool can backtrace the exact reference chains causing objects to be retained. -- especially if you have the luxury of debugging a 16MB heap, rather than (say) a 2+GB heap. The really annoying OOMEs in my experience are those that aren't really object heap exhaustion -- but other depletions that still get reported as OOME. Sometimes, increasing your object heap makes these worse (eg by allowing less space for non-heap JVM structures). At least starting in Java 6, these "other OOMEs" tend to have different messages.

14 points by hollywoodcole 19y ago

As a mental exercise think how many people that call themselves "Java developers" would be able to troubleshoot the issues this guy encountered. I love statements like "take a look the code below" followed by what appears to be perfectly normal code to me and then "the problem in the code above is obvious".

bayareaguy 19y ago
This guy definitely deserves credit for focusing on the problem. Most java developers I know would have tried some cheezy workaround like periodically restarting the process. As a consequence things like this go unsolved for years. This is actually a common issue whenever you have long-lived processes which suck in third-party code. Half the complaints I see about browsers these days is that they leak memory. I remember a similar problem in C++ years ago with a poorly coded initializer. One of the core dumps of an X application I looked into had over 50 megabytes of copies of the string "Helvetica".

asmosoinio 19y ago

I read it, understood some of it -- and am now happy not to be this guy. And I do consider myself a "Java developer", even though I have not been working with Java lately.

huherto 19y ago

Excellent article, it was invaluable to me a couple of years ago when I was trying to find a memory leak that was placing a very large project in jeopardy.

gojomo 19y ago

Though he doesn't mention which Java version he's using, nowadays some core bundled facilities can make such diagnoses a lot quicker. 'jmap -histo' give you instance counts by class in a running JVM -- so over a period of unexpected memory retention, or the period just before an OOME, you can identify supspiciously overrepresented types. A binary heap dump and then browse with the 'jhat' tool can backtrace the exact reference chains causing objects to be retained. -- especially if you have the luxury of debugging a 16MB heap, rather than (say) a 2+GB heap. The really annoying OOMEs in my experience are those that aren't really object heap exhaustion -- but other depletions that still get reported as OOME. Sometimes, increasing your object heap makes these worse (eg by allowing less space for non-heap JVM structures). At least starting in Java 6, these "other OOMEs" tend to have different messages.