Java memory not release when image stacks closed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Java memory not release when image stacks closed

David A. Sebok
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.
Reply | Threaded
Open this post in threaded view
|

Re: Java memory not release when image stacks closed

Albert Cardona
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
Reply | Threaded
Open this post in threaded view
|

Re: Java memory not release when image stacks closed

Michael Schmid
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