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. 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. |
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 |
Hi David, Albert,
an easy way out would be a plugin that calls System.gc(). You can do this - either once (so you have to call it), - or repeatedly: while (true) { System.gc(); IJ.wait(repetition_time_in_milliseconds); } - or register as an ImageListener and call it in the imageClosed(imp) thread. For the repetitive options, you could do start the plugin in the StartupMacros.txt file in the "AutoRun" macro. Michael ________________________________________________________________ On 12 May 2008, at 16:23, Albert Cardona wrote: > 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 |
Free forum by Nabble | Edit this page |