Posted by
Albert Cardona on
May 12, 2008; 2:23pm
URL: http://imagej.273.s1.nabble.com/Java-memory-not-release-when-image-stacks-closed-tp3696247p3696248.html
David,
> If I open multiple "large"(~100mb)image stacks and then close them, the
> memory monitor will show a decrease in memory (after a variable lag) but the
> Windows Task Manager does not show any decrease in Mem Usage for the Java
> VM, even after an overnight wait. The Virtual Memory size stays at the
> largest memory ever used during a single session. The "Java VM" Memory
> Usage will decline if other programs are loaded. But when new images are
> loaded, there can be a big lag in ImageJ while "empty" memory is paged back in.
>
> I first noticed this problem when I upgraded from 1.39c to 1.39q. It
> forced me to revert to 1.39c. I was hoping this problem would have been
> fixed when I upgraded to 1.41b but it is still there.
>
> It sort of seems like the Java VM garbage collector in ImageJ has been
> deliberately disabled.
Yes, it has. ImagePlus.flush() method no longer calls System.gc().
See:
http://imagejdocu.tudor.lu/imagej-documentation-wiki/how-to/imagej-performance-tuning> This would be okay if the system were only being
> used by ImageJ. But as I normally have multiple applications starting and
> stopping, this means that the performance hit to ImageJ becomes such that it
> has to be stopped and restarted.
>
If you mean other applications running within the same JVM, then it
should not be an issue: the JVM will free memory on the heap as it sees fit.
If you mean other applications in the operating system in general, keep
in mind that the JVM, once it has enlarged its heap (up to a maximum
determined by -Xmx argument), it will never shrink back. So it will page
and look big and all. But that's not an ImageJ problem, rather a JVM
problem.
If you are planning on using the JVM along with other applications, use
the smallest maximum heap possible (as defined by -Xmx), necessary to
have simultaneously open the images you need. Small heap sizes will also
improve a lot the performance of the garbage collector.
Albert
--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona