Re: Java memory not release when image stacks closed

Posted by Michael Schmid on May 13, 2008; 9:43am
URL: http://imagej.273.s1.nabble.com/Java-memory-not-release-when-image-stacks-closed-tp3696247p3696249.html

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