Memory not clearing over time

Usage & Issues
, ,
#23

I just wanted to thank you Curtis for the trick on pressing on the status bar to activate the garbage collector. That is VERY convenient.

I had enough information to seriously track what was going on and I saw that my 3 view, inside Pet Ct viewer wasn’t freeing memory. I finally found a reference to the parent inside a child. When doing my dispose, I needed to null the reference inside the child.

When you have the right tool, you can find the problem. Thanks again for pointing out something which I had obviously missed.

1 Like
#24

Dear all,
I’m sorry to reactivate this old thread, but we continue to see this “memory leak?” when importing using Bio-formats and running Java 1.8. Using Utilities/Monitor memory, we find the memory is not being released after opening our data files in FIJI or in ImageJ1, but this seems to be under specific conditions. I’ll describe our observations below in the hopes that it might help.
Here is a general description of what happens when we import a 3 channel 900 image stack.
Running FIJI 1.51j (ImageJ2) with Java 1.8 the memory usage jumps up to ~1426MB and doesn’t go down when the image is closed. If we open another image, memory usage jumps again to ~2784MB and remains there even after closing the image. Clicking on the tool bar brings down the memory usage slightly (to ~2734MB), but even after clicking several times it doesn’t drop beyond this. A Fiji restart is necessary to complete analysis of all datasets.

Thus, we have similar observations to those described earlier in this thread.

  1. Garbage collection by pressing the tool bar does not release it.

  2. We have found the problem exists when importing using Bio-Formats for both ImageJ1 and ImageJ2(FIJI) as long as they are using 1.8. No problem is noted if using ImageJ1 or an ImageJ1 (FIJI) using Java 1.6.

  3. We also do not find a problem (with any of the versions) with the memory being released if they are simply opened through the normal ImageJ file open menu.

  4. We have tested using Macs running either 10.10.5, 10.9.5, or 10.12 with a range of ImageJ versions, Java versions and Bio-Formats releases including the latest updates. Here are a few of most up to date combinations we’ve tried.

    Mac OSX 10.12.3, FIJI ImageJ 2.0.0-rc-59/1.51j; Java 1.8.0_66 (64bit) BioFormats 5.1.10
    Mac OSX 10.12.3, FIJI ImageJ 2.0.0-rc-59/1.51j; Java 1.8.0_66 (64bit) BioFormats 5.2.0

    Mac OSX 10.12.3, FIJI ImageJ 2.0.0-rc-59/1.51j; Java 1.8.0_66 (64bit) BioFormats 5.3.2
    Mac OSX 10.12.3, FIJI ImageJ 2.0.0-rc-59/1.51j; Java 1.8.0_121 (64bit) BioFormats 5.3.2

    Mac OSX 10.12.3, FIJI ImageJ 2.0.0-rc-59/1.51j; Java 1.8.0_66 (64bit) BioFormats 5.4.0
    Mac OSX 10.12.3, FIJI ImageJ 2.0.0-rc-59/1.51j; Java 1.8.0_121 (64bit) BioFormats 5.4.0

    Mac OSX 10.12.3, FIJI ImageJ 2.0.0-rc-59/1.51k; Java 1.8.0_121 (64bit) BioFormats 5.4.0

  5. Some potentially new observations that we can add here. We have noted this “memory leak” occurs when stack viewing is set as HyperStack. If we import with stack viewing as something other than HyperStack, the memory leak is not apparent. That is, if we use ImageJ standard, the garbage collector seems to work fine. The three channels are collapsed into a single stack, so it makes analysis difficult, but the memory issue is gone.
    We’ve also noted that if we use the HyperStack viewer and split the channels on import or split focal planes on import, the memory leak is not apparent. Since our datasets have only one focal plane, the stacks look the same, but the memory is released once the image is closed and the garbage collector runs. We’ve also checked by simply opening and closing images without running the garbage collector and the memory also gets released automatically when needed. We found this behavior on all our machines that we tested. This has provided a work around for use in our macros and plugins by setting the options to split focal planes.

  6. Can anyone else repeat these observations on a Mac? If you do not find this memory problem, can you please post which versions of ImageJ, Java, and operating system that you are using?

  7. A previous post by Curtis Rueden indicated that an upgrade to 10.12 solved his problem, but it did not for us. I know you are quite busy, but if you read this Curtis, could you post specifically which versions worked for you? Maybe we can make sure we are trying a similar configuration.

Thanks,
George

#25

Thank you for the detailed bug report, @George_Patterson.

I was unable to reproduce the bug under the following configurations:

  • MacOS 10.12.4; Fiji Is Just ImageJ 2.0.0-rc-59/1.51k; Java 1.8.0_112 (64bit); Bio-Formats 5.4.0
  • MacOS 10.12.4; Fiji Is Just ImageJ 2.0.0-rc-59/1.51k; Java 1.8.0_121 (64bit); Bio-Formats 5.4.0

The missing variable is: which file format(s) are you reading? Can you share a link to a sample bug-triggering image? If you save as TIFF locally, and open that, do you experience the issue using File :arrow_forward: Import :arrow_forward: Bio-Formats on that TIFF file?

In my tests, I used a 4D TIFF file saved with ImageJ, 1GB in size, with uint8 sample values, 85 time points and 33 focal planes.

#26

Curtis,
Thank you for your help and sorry for the delay in responding.
Also, I apologize for leaving out such critical information as the file format.
These are Micromanager .ome.tif files. I can reproduce the behavior described in my earlier post from image stacks produced using the demo configuration if that makes it possible for you to easily test. Otherwise, I will be happy to provide a link to a file. These are from MM 1.4.22 if that makes a difference. As a further test, I found using the demo configuration that I could reproduce the “memory leak” with only two channel stacks. Again, it only occurs when using the Hyperstack viewer and not splitting channels, etc. If it is simply one channel, there is no problem.
Unfortunately, my IT support has not had a chance to upgrade my desktop to 10.12 and I do not currently have access to our most up to date machine. As soon as I do have access and/or my machine is upgraded, I’ll try the configurations you have indicated.
Thanks again and let me know if you need a link to one of our data files.
Best regards,
George

#27

Thanks for the additional details, @George_Patterson. Unfortunately, I personally do not have the bandwidth currently to investigate this issue further. However, I mention OME Bio-Formats team members @dgault and @melissa in case they have time and/or ideas.

#28

Curtis. No worries. Thanks for the time you’ve invested already.
Which configuration in Mac that is known to work is very helpful.
Best,
George

#29

Hi George,

Thank you for your help and the work you have done analysing this issue. We have been investigating this on the Bio-Formats team as well and have recently gone through each component in Bio-Formats to identify and attempt to solve any potential memory leaks.

Your observation that using Hyperstack causes a memory leak is a new discovery and I was indeed able to reproduce the same findings as you had reported. I will be continuing to investigate this from our side by going through memory heap dumps to attempt to isolate the problematic components.

David Gault

2 Likes
#30

Just as an update, the first screen shot below is a heap dump taken when the image window is still open:

1054×414 53 KB

The below screenshot is a heap dump taken once the image window has been closed and the garbage collection has been called. I can confirm that the close method on StackWindow is processed and the ImagePlus and ImageCanvas objects are set to null at that point.

1228×630 88.8 KB

#31

Hi David,
Thanks for looking into this.
Sorry for my ignorance, but could you elaborate a bit?
Am I understanding correctly from those screen shots that the Bio-Formats importer is working properly?
If so, does this indicate as Curtis suggested in earlier post that the problem may be some change in Java after version 1.6 triggered by Bio-Formats, but only when using Hyperstack?
We have been monitoring memory usage using Plugins>Utilities>Monitor Memory. Is this applicable to monitoring this problem?
Again sorry for my ignorance and thanks for your help.
George

#32

Dear @George_Patterson,

If you don’t want to dig deeper, it is applicable.

Just for clarification: when you open an image with Bio-Formats in the Hyperstack Viewer, close said image again, and click the status bar, the Memory Monitor does not show a decrease in memory? Or are we talking about automated Garbage Collection once an image is close, i.e. without clicking the status bar?

I cannot reproduce the issue on Ubuntu 16.04.1, Java 1.8.0_66, Bio-Formats 5.5.0. Closed images get properly flushed when a Hyperstack Viewer is closed and garbage collected both automatically (when e.g. a new file is loaded and the maximum heap size is approached) and manually.

Any news on the macOS front, @dgault?

Best,
Stefan

1 Like
#33

Hi Stefan,

Just for clarification: when you open an image with Bio-Formats in the Hyperstack Viewer, close said image again, and click the status bar, the Memory Monitor does not show a decrease in memory?

When the status bar is clicked, It does not show a decrease in memory equal to that of the stack. It does show a decrease of ~35MB. Our stacks are typically ~1.4GB.

Or are we talking about automated Garbage Collection once an image is close, i.e. without clicking the status bar?

We are unable to force garbage collection with the status bar or automatically.
And I didn’t expect it to work but tried anyway, this command
call(“java.lang.System.gc”);
in a macro didn’t decrease the memory either.

I cannot reproduce the issue on Ubuntu 16.04.1, Java 1.8.0_66, Bio-Formats 5.5.0.

Thanks for testing on Ubuntu. We cannot reproduce this behavior on our Windows machines but had no opportunity to test Ubuntu. Garbage collection works fine automatically or when the status bar is clicked.
We only note the leak on our Apple machines under the conditions described previously.

In the interim I have checked on some .lsm files and find the same behavior as the ome.tif files.
We also see this behavior with the “Mitosis” sample stack (from Fiji) if we save it to our machines and then reopen using Bioformats.

Thanks,
George

Out of memory with Find Particles / Bio-Formats Plugin
#34

Hello, was this issue resolved in the end? I’m experiencing it right now with the latest FIJI/Bioformats opening .nd2 files on W7 32GB RAM.

Else, I’ll continue to restart FIJI periodically.

Thanks,

Darren

#35

Hi Darren,

Im afraid the issue is still present when using the Hyperstack view. This is something which we do continually look at and we have made a number of performance improvements within Bio-Formats and reviewed potential memory leaks from open streams in all our readers.

1 Like
#36

Darren,
I’m not certain that it will help you much, but we’ve found that checking one of the split planes options when using Hyperstack view avoids the memory problem. That is, the garbage collector seems to work properly once you close the stack and reopen another.

If your datasets have multiple channels, multiple z positions, and multiple time points, this little trick will be of little use to you. But if one of those three in your datasets is not multi-dimensional, it might save you periodic FIJI restarts.

George

2 Likes
#37

A workaround for multi-dimensional images that works for me is to open the files with the ‘split_channels’ setting checked, then merge the channels afterwards using ‘run(“Merge Channels…”)’.

I am using Bio-Formats to merge multi-dimensional (z-stacks with 3 colour channels) by time using the ‘group_files’ function in bio-For

This helps me when I need to group multi-dimensional files with the

I added some example code:

firstFileName = "some_file_path_S001.tif"
searchPattern = "S001.tif"

run("Bio-Formats Importer", "open=[" + firstFileName + "] color_mode=Default group_files rois_import=[ROI manager] split_channels view=Hyperstack stack_order=XYCZT file_name axis_1_number_of_images=10 axis_1_axis_first_image=1 axis_1_axis_increment=1 contains=" + searchPattern);

// Change names to simplify merge
for (j = 0; j < nImages; j++) {
   selectImage(j+1);
   rename("C-" + (j+1));
}
// Merge images of up to 5 dimentions
		if(nImages == 1){
			// DO nothing
		}else if(nImages == 2){
			run("Merge Channels...", "c1=[C-1] c2=[C-2] create");
		}else if(nImages == 3){
			run("Merge Channels...", "c1=[C-1] c2=[C-2] c3=[C-3] create");
		}else if(nImages == 4){
			run("Merge Channels...", "c1=[C-1] c2=[C-2] c3=[C-3] c4=[C-4] create");
		}else if(nImages == 5){
			run("Merge Channels...", "c1=[C-1] c2=[C-2] c3=[C-3] c4=[C-4] c5=[C-5] create");
		}

Thanks to @Christian_Tischer For suggesting this fix.

6 Likes
Imagej Correct 3D drift memory leak
#38

Thanks A LOT to you for posting it here! This is awesome! Most people just run away with a solution once it works for them.

2 Likes
#39

Is this still an active issue that memory is not clearing over time? I think we face a similiar issue with Fiji on Windows x64.

#40

This is still an active issue but I suspect it may not be the same as what you are seeing based on the other thread (Out of memory with Find Particles / Bio-Formats Plugin)

1 Like
#41

Thanks. Sorry for cross-posting.

#42

I found a solution for some case:

I call the FIJI plugin class and method in a script to process files. The plugin is located in the standing menus unique to FIJI compared to basic imagej.(not custom plugins). These unique standing is located in Fiji_Plugins-2.0.0-SNAPSHOT.jar.

When I process file one-by-one, the memory usage accumulate and finally shows imagej’s error of out of heap space memory (~380MB) even though the physical memory of PC is ample.

I just add one line in the end and the problems solved: the memory not goes up anymore no matter how many images I process.

This line is :
updater.stop();

It is associated with a inner class called updater:

  private class Updater
    extends Thread
  {
    long request = 0L;
    
    Updater()
    {
      super();
      setPriority(5);
      start();
    }
...

Hope this will help if your script calls these FIJI’s standing basic unique plugins.

Bio-formats importer in Jython for czi files