Posted by
Aryeh Weiss on
Dec 07, 2015; 5:46pm
URL: http://imagej.273.s1.nabble.com/imagej-and-Java-1-8-tp5015143p5015164.html
Thanks to Wayne and Mark for their replies.
On 07/12/2015 5:02 PM, Mark Hiner wrote:
> Hi Aryeh,
>
>> It would be very helpful if you could figure out which plugin is causing
>> the memory leak.
>>
>> When the memory leak occurs, you can acquire a heap dump to take a snapshot
>> of object allocations in Java. At that point the memory leak culprit often
>> becomes obvious.
>>
>> On the wiki we have instructions[1] and a practice exercise[2] for
>> acquiring and analyzing heap dumps. If you can acquire the heap dump but
>> aren't sure how to interpret the results, you can also save it as a .hprof
>> file and share it here so we can help analyze it.
Thanks for this information. I decided to run IJ, do a heap dump before
running a script that opens a few 1.3Gpixel images, then run it after,
then close the images and get a heap dump when the images have been
closed but the memory is not freed (which is reproducible).
At this point I learned that generating 6GB+ heap dumps is a great way
to run out of disk space in a hurry :-). So I will do this again, this
time writing to an external disk and deleting the dumps (but that will
have to wait until tomorrow).
Compressed, the dumps are about 1 GB . In order to send it to you, I
will probably need to send it to an FTP server (like I have done with
bio-formats. DO you have a server to which I can send the dumps?
> Best,
> Mark
>
> [1]
http://imagej.net/Debugging#Debugging_JVM_hangs> [2]
http://imagej.net/Debugging_Exercises#Exercise_7:_Out_of_memory>
> On Sun, Dec 6, 2015 at 2:23 PM, Rasband, Wayne (NIH/NIMH) [E] <
>
[hidden email]> wrote:
>
>> On Dec 6, 2015, at 5:24 AM, Aryeh Weiss <
[hidden email]> wrote:
>>> I have noticed that when using Fiji with Java 1.8, the response
>>> gradually gets slower, until eventually
>>> I need to restart Fiji. The issue seems to be connected to screen
>>> updates, but I cannot pin it down to a single item, although the ROI
>>> Manager seems to often be involved.
>>> For example, toggling "Show All" in the ROI manager tends to become really slow.
>>>
>>
>> The gradual slowdown of ImageJ with Java 1.8 on OS X appears to be related
>> to setting the menu bar at the top of the screen when image windows are
>> activated. With the ImageJ 1.50e update, the Stack to Images, Window>Tile
>> and Window>Cascade commands, and non-batch mode macros that process
>> multiple images, attempt to minimize setting the menu bar.
I noticed the slow update of the menu bar.
I think that this problem is exacerbated on a dual monitor OSX system,
because whenever windows are transfered between monitors the menu bar is
updated.
>>> Now, the memory monitor shows 6.8GB in use, although I have very little
>> open. Double clicking on the Fiji window does not appear to have forced GC.
>>
>> This looks like a memory leak. Clicking in the ImageJ status bar, or in
>> the Memory Monitor window, runs the Java garbage collector, which reclaims
>> unused memory unless there is a memory leak. Sometimes you need to click
>> several times to reclaim all unused memory. Memory leaks can also cause
>> ImageJ to slowdown. Do you see the memory leak when using Java 1.6? It
>> would be very helpful if you could figure out which plugin is causing the
>> memory leak.
>>
>>
I have not been able to pin it down. There is a python script that I run
which leaves 3 1.3Gpixel images open, and when that is finished, the
memory usage appears appropriate. But when I close the images, and
attempt to garbage-collect, them memory is not freed up.
I have not been able to test it under Java 1.6 because when I run my
macro, I get the following error when loading the large image:
Invalid memory access of location 0x1aa84b080 rip=0x7fff8a310f1a
fijiJ6.sh: line 3: 92360 Segmentation fault: 11
$J6/bin/$($IJ_HOME/Contents/MacOS/ImageJ-macosx --dry-run | sed 's/
-Djava.ext.dirs=[^ ]*//')
The code that is run at this point is:
for w in WindowManager.getNonImageTitles():
if (w[:-3] != '.py' and w[:-4]!='.ijm' and w[:] != 'Recorder') and
w[:] != "Command Finder" and w[:] != "Memory":
print w
WindowManager.getWindow(w).close()
for w in WindowManager.getImageTitles():
WindowManager.getWindow(w).close()
op = OpenDialog("Choose input image...", "")
path = op.getDirectory()+ op.getFileName()
inputName = op.getFileName()
inputDir = op.getDirectory()
inputPath = inputDir + inputName
if inputName[-4] == ".":
inputPrefix = inputName[:-4] # assumes that a suffix exists
else:
inputPrefix = inputName
inputImp = ImagePlus(inputPath)
inputImp.show()
ImageConverter(inputImp).convertToGray8()
inputIp = inputImp.getProcessor()
The program fails before the inputImp.show() command paints the window.
If I load this image outside of the macro (just by opening with the
menu), then it will take a long time to open, but it will open properly.
This happens in Java 1.6
In Java 1.8 it opens as expected, my script runs and all is well for a
while, until things get slow.
Best regards,
--aryeh
--
Aryeh Weiss
Faculty of Engineering
Bar Ilan University
Ramat Gan 52900 Israel
Ph: 972-3-5317638
FAX: 972-3-7384051
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html