Memory not clearing over time

memory
bio-formats
Tags: #<Tag:0x00007fb87e669ef8> #<Tag:0x00007fb87e669d90>

#21

@ilan How are you measuring the memory use?

You have seen the “Why does ImageJ not release any memory back to the system?” side bar of this Troubleshooting section, right?

Those two facts are unrelated. You can use the JVisualVM profiler to troubleshoot the memory use without needing to use your plugin.

No, Bio-Formats is a library for reading life sciences formats, and converting them to the OME-XML schema. It is not a general solution for image formats beyond that. The general image I/O solution for ImageJ2 et. al is SCIFIO, which has a Bio-Formats format plugin. And the even more general I/O solution (not necessarily images) is part of SciJava Common.


#22

In fact I didn’t know that clicking on the status bar would activate the garbage collector.
I will pass that on to the user who is having problems. It is one more test to see what might be happening.


#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.


#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


#30

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

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.


#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


#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