0

OK, I have a memory leak. It is most likely in the GUI or an ExecutorCompletionService. What is the options for monitoring program memory?

Yes, I get out of memory error. I have set -XX:+HeapDumpOnOutOfMemoryError on the vm arguments in eclipse to generate the dump file. The situation is there is a ExecutorCompletionService running a thread pool of computationally intensive tasks. The threads signal the gui thread with intermediate results.

I'm in the process of reviewing the unit test for the ExecutionController class, and was wondering if I can integrate memory monitoring into the unit test.

Regarding the profiling options, I did this successfully last month, but I don't remember the procedure or the pro filler used. I opened a separate window and monitored real time snap shots from an externally running monitor. I vaguely remember some difficulty in identifying the precise class member that had the memory leak, but enough information was provided to solve the previous problem.

I'll try the suggested monitoring options in the near future.

  • 2
    you can attach profiler with java process and monitor – jmj Apr 08 '13 at 01:56
  • Please provide more details. Are you getting `OutOfMemory` errors? – PM 77-1 Apr 08 '13 at 01:57
  • @PM77-1 - presumably yes. But not really relevant. He doesn't want us to actually help him solve the problem. He wants us to tell him how to solve the problem himself. – Stephen C Apr 08 '13 at 02:49
  • I ended up using Jconsole to monitor the memory, with breaks set in the code to run portions of the code. It was also helpful to hit pause while the memory was visually increasing. The culprit was a series of toString members that caused an infinite recursion loop. –  Apr 20 '13 at 11:26

2 Answers2

1

The memory leak could be either due to stack or heap size of the JVM being exceeded. The first step in identifying memory leak is confirming if there is one. Please try increasing the heap and the stack space using JVM command line options. -xmx and -xss are options to increase heap and stack size respectively.

Once it's confirmed, there are variety of tools that help would narrow down to the offender block of code to identify the leak. My favorite is to take a dump of the running threads at the time of out of memory exception, assuming that it occurred, and examining the dump. Please try java -Xrunhprof:help for more details. I use Memory Analyzer (MAT), an eclipse plug-in to analyze the dump.

Also, Java Memory Extensions provides great details on how to introspect the running JVM with regard to the threads, heap and stack sizes. If you are using JDK 1.6 and above, it ships with visual vm, a profiling tool to aid in this purpose as well.

kuriouscoder
  • 5,394
  • 7
  • 26
  • 40
  • I did increase the maximum and minimum heap size, but that didn't help too much. More of the intensive tasks evaluated. I will look at the memory dump in the near future. I'm using 1.7, so I may look at memory extensions if needed. –  Apr 09 '13 at 03:49
0

As of JDK 6 a profiling tool called jvisualvm is included in the \bin directory. You can scan CPU usage, monitor memory and threads, etc.

You can read more about it here.

Bizmarck
  • 2,663
  • 2
  • 33
  • 48
  • I ended up using Jconsole to watch the memory, with breaks set in the code. It was a little helpful to press pause while the memory was suddenly increasing. In this case, the cause was an infinite recursion loop set up by several toString members. –  Apr 20 '13 at 11:28