Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

New AppDynamics Software Hunts Memory Leaks, Finds Root Cause, and it's All in Production

  • submit to reddit
Java memory issues are common and often difficult to diagnose.   Profilers and other tools are great, but they have their blind-spots.  For production environments, profilers can constitute a lot of overhead.  They rely on heap dumps instead of runtime data, and the heap dump approach is not suitable for large heap sizes that are commonly found today.  Some profilers have non-heap dump approaches, but they only capture shallow object sizes.  This was AppDynamics' view of the production memory monitoring and diagnostics space when they decided to get into the game.  With today's release of AppDynamics 3.0, they're showing companies the value of a new approach - memory leak detection and root cause diagnostics in the production environment.

“Memory leaks create havoc for countless organizations with mission-critical java applications,” said AppDynamics CEO Jyoti Bansal. “Best case scenario, a memory leak causes your system to slow down, dragging application performance well below established SLAs. Worst case scenario, your servers crash completely and you don’t know why."

Here is AppDynamics' ideal memory troubleshooting flow:

You can find legacy tools that identify memory leaks pretty effectively, but AppDynamics says that their release today is the first that also provides analytics that can determine the root cause of the leaks within the production environment.  This is important because more and more companies want to evaluate their caching strategy.  

AppDynamics 3.0 enables real-time Java heap monitoring, garbage collection memory pool monitoring, an shows the correlation between the heap and the major and minor GC collections:

Root cause diagnostics in AppDynamics 3.0 will look at code paths and transactions and determine which ones are accessing the collection.  Bansal lists some of the other distinguishing features of AppDynamics:

  • Low-cost algorithm for object deep size calculation
  • Automatic Java collection instrumentation
  • Dynamic access/allocation code path analysis
  • Live object instance tracking
  • Automatic memory leak detection with best-fit linear regression analysis

AppDynamics 3.0 also builds on its feature set for highly distributed cloud environments.  Bansal asserts, “Cloud applications require a performance management solution that can dynamically discover, map, instrument and monitor the environment - even when 100 nodes appear or disappear
on the fly.”

3.0 includes a new dynamic cluster aggregation feature that uses self-learning baselines to intelligently track instance lifecycles.  The new version also facilitates up to 1000 cloud node agents reporting to a single AppDynamics controller.  Finally, 3.0 includes dozens of customer-requested features:


Andrew replied on Tue, 2010/10/05 - 2:25am

It bugs me: How to hunt memory leaks in Java applications.

I thought that Java does not have delete() or free() functions.

Therefore, I thought that you do not have to worry about memory leaks as you do in C. In fact, that was one of the selling points of the Java language. Right?

So how exactly can you resolve memory leak in Java code?


Andrew McVeigh replied on Tue, 2010/10/05 - 5:39am in response to: Andrew

memory leaks happen the opposite way in java -- they are caused by what you hold onto (remember) rather than what you forget (like in C++).  it's an easier problem in java, simply because you can find the objects.

memory leak tools allow you to work out which objects you are hanging onto.

and unlike in C++, looking for memory leaks is generally done closer to the end of a project when you need to ensure the memory consumption is static.

Andrew replied on Tue, 2010/10/05 - 7:39am in response to: Andrew McVeigh

Hi, Thanks. I got it. As regarding to memory leaks Java is just like C. In Java you should check that you do not hold a reference to a Java object you want to be deleted and wait until GC does the job. In C if you want to delete some object you should call delete() or free().

Andrew McVeigh replied on Tue, 2010/10/05 - 8:22am in response to: Andrew

sort of but we also need to consider in C/C++ where we forget to call delete, but further have also lost the pointer that we would call delete on so we cannot ever call it now.


in java - memory leaks are caused by objects you hold onto that you don't need anymore

in C/C++ - memory leaks are caused by forgetting to call delete/free(), or losing the pointer (i.e. when it goes out of scope) on which we need to call delete/free().

And the latter is the hardest to debug, because there's no easy way to find these spaces you have allocated but no longer have the pointers to. smart tools like purify can do it.

In contrast, in Java, you simply walk through the object tree of all the variables in your program looking for stuff that shouldn't be there.

Loren Kratzke replied on Thu, 2010/10/07 - 8:40pm in response to: Andrew

Just to clarify, a memory leak in C will tend to crash the OS where as a memory leak in a Java program will only crash the virtual machine. So from an OS perspective, Java does not have memory leaks.

Freeing the last reference to an object is "virtually" the same as delete() or free() from the perspective of your program.

The concept of waiting until the GC runs never enters your mind unless you are doing realtime Java or you are experiencing long GC times that noticibly pause your program. But you can tune the GC and optimize code to remedy that situation. Not a problem.

Carla Brian replied on Sat, 2012/06/09 - 3:12am

I am new to this one. I will read more on this .I think it is reliable. - Thedore Stroukoff

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.