Hi,
I am running ImageJ under the Fiji application on a PC running windows XP. When I try to change the memory allocation under the options menu there is no effect on the amount of memory allocated after restarting the program. This occurs regardless of whether I try to increase or decrease it. I noticed that the image j cfg file was unchanged by using this command, but also noted that the amount of memory used was different from what was denoted in the cfg file-- so the memory allocation must come from somewhere else, but I don't know where to look! Thanks for any insight. Susan Travers |
Here is where it is getting the information from:
"public long getMemorySetting() { if (IJ.getApplet()!=null) return 0L; long max = 0L; if (IJ.isMacOSX()) { if (IJ.is64Bit()) max = getMemorySetting("ImageJ64.app/Contents/Info.plist"); if (max==0L) { max = getMemorySetting("ImageJ.app/Contents/Info.plist"); } } else max = getMemorySetting("ImageJ.cfg"); return max; } " So...from skimming the code, it looks like it gets the number from ImageJ.cfg. The numbers are probably different because the number in ImageJ.cfg is in bytes, not megabytes. Have you tried changing the value in the .cfg file (make sure it's the right one just in case you accidentally have a copy)? Also, you have to restart imageJ for the change to take effect and you can't be running imageJ as an applet or by command line.
|
In reply to this post by spt
Hi Susan,
On Tue, 7 Jun 2011, Susan Travers wrote: > I am running ImageJ under the Fiji application on a PC running windows > XP. When I try to change the memory allocation under the options menu > there is no effect on the amount of memory allocated after restarting > the program. This occurs regardless of whether I try to increase or > decrease it. I noticed that the image j cfg file was unchanged by using > this command, but also noted that the amount of memory used was > different from what was denoted in the cfg file-- so the memory > allocation must come from somewhere else, but I don't know where to > look! Beware, on Windows it might be that you are not allowed to write to C:\Program Files (or whatever the localized name is on your computer), and therefore the .cfg might not be writable by you. If that is not the issue, please start Fiji from the command line as described in http://fiji.sc/Debugging_intro#Command_line_debugging The most likely reason why your Fiji does not start with exactly the same amount of RAM as specified in the .cfg file is that Java often cannot allocate as much RAM due to Operating System specific reasons, and rather than fail, Fiji tries again with less RAM. Ciao, Johannes |
Hi Susan,
On Tue, 7 Jun 2011, Susan Travers wrote: > Actually, the program is starting with more memory than allocated in the > ImageJ.cfg file. That is strange. If you call the program with --dry-run, does it show any -Xmx<number>g settings? > I did try starting the program from the command line fiji-32 --console, > and the program came up but then I wasn't sure what to do next (just > bringing it up, changing the memory did not do anything)... So there was no error message on the console. Interesting. > maybe I need to include the memory change at that point in the command > line. I'm really confused b/c I don't know cfg file the program is > using... It might be that you updated ImageJ to a version that writes ImageJ.cfg, but the original Fiji would have written jvm.cfg (in a different format, hence the name change). But of course you can always pass the "--mem=3g" option (adjusting the amount of memory you want to reserve for Java accordingly) to Fiji if you want. Ciao, Johannes |
Hi Johannes
On Wed, 8 Jun 2011, Johannes Schindelin wrote: > Hi Susan, > > On Tue, 7 Jun 2011, Susan Travers wrote: > > > Actually, the program is starting with more memory than allocated in the > > ImageJ.cfg file. > > That is strange. If you call the program with --dry-run, does it show any > -Xmx<number>g settings? I tried using the commandline options --dry-run or --help with either the -win64.exe or -win32.exe, there were no output as in the linux version. I tried Madison and Heidelberg on Win7 with java 1.6.0_24, and both versions behaved the same. -- Pang (Wai Pang Chan, [hidden email], PAB A087, 206-685-1519) The Biology Imaging Facility (http://depts.washington.edu/if/) |
In reply to this post by dscho
Dear Susan,
On Wed, 8 Jun 2011, Susan Travers wrote: > I believe that I lost the last message that you sent me yesterday > regarding changing the memory allocation with Fiji. (sorry). Heh, no need to be sorry. Furthermore, since I make a point of answering to the mailing list, chances are that you can find my mail here: http://news.gmane.org/gmane.comp.java.imagej > Anyway, I am really baffled by this. I see that the jvm.cfg file (which > is in the same subdirectory as the fiji-win32.exe file) reflects the > changes that I make by going into "options"/"memory", but those changes > don't get reflected the next time I start Fiji-- it seems as if the > program is deciding on how much memory to use, independent of any > changes that I make. Then it might be a good idea to start Fiji with --dry-run to see what options are passed to Java and ImageJ, respectively. See http://fiji.sc/Debugging_intro#Command_line_debugging for details how to start Fiji from the command line. > (I am at least a little less confused than before, because I realized > that I had a copy of image j that was totally unrelated to the Fiji > version that I am using, so initially I was looking at the wrong config > file; I have now deleted the plain ImageJ version). > > Not being able to change the memory is not too big a problem, but I > would like to be able to figure this out. Thanks for pointing me in any > likely direction. > > PS, the version info is ImageJA 1.45i Java 1.60_24 32-bit Yep, that is up-to-date. If worse comes to worst, you can always start Fiji from the command line and specify an amount of RAM directly with the --mem=<amount> (where <amount> is something like 1500m). Ciao, Johannes |
In reply to this post by W. Chan
Dear Chan,
On Wed, 8 Jun 2011, W. Chan wrote: > Hi Johannes [please Cc: me if answering my mail; if you address somebody in a group, you look into her face, too, not elsewhere] > On Wed, 8 Jun 2011, Johannes Schindelin wrote: > > > On Tue, 7 Jun 2011, Susan Travers wrote: > > > > > Actually, the program is starting with more memory than allocated in > > > the ImageJ.cfg file. > > > > That is strange. If you call the program with --dry-run, does it show > > any -Xmx<number>g settings? > > I tried using the commandline options --dry-run or --help with either > the -win64.exe or -win32.exe, there were no output as in the linux > version. I tried Madison and Heidelberg on Win7 with java 1.6.0_24, and > both versions behaved the same. As described in http://fiji.sc/Debugging_intro#Command_line_debugging on Windows, you need to pass the --console option, too. Ciao, Johannes |
Thanks Johannes. That works well.
On Thu, 9 Jun 2011, Johannes Schindelin wrote: > Dear Chan, > > On Wed, 8 Jun 2011, W. Chan wrote: > > > Hi Johannes > > [please Cc: me if answering my mail; if you address somebody in a group, > you look into her face, too, not elsewhere] > > > On Wed, 8 Jun 2011, Johannes Schindelin wrote: > > > > > On Tue, 7 Jun 2011, Susan Travers wrote: > > > > > > > Actually, the program is starting with more memory than allocated in > > > > the ImageJ.cfg file. > > > > > > That is strange. If you call the program with --dry-run, does it show > > > any -Xmx<number>g settings? > > > > I tried using the commandline options --dry-run or --help with either > > the -win64.exe or -win32.exe, there were no output as in the linux > > version. I tried Madison and Heidelberg on Win7 with java 1.6.0_24, and > > both versions behaved the same. > > As described in > > http://fiji.sc/Debugging_intro#Command_line_debugging > > on Windows, you need to pass the --console option, too. -- Pang (Wai Pang Chan, [hidden email], PAB A087, 206-685-1519) The Biology Imaging Facility (http://depts.washington.edu/if/) |
In reply to this post by dscho
I also found that changing the memory in Edit-Options-Memory & Threads
had no effect. There is a file called jvm.cfg in the Fiji folder, which updated to the new memory, but Fiji didn't read it, even though it had just written to it. I created a new file, ImageJ.cfg. Fiji did honour the memory setting in this file, but won't write to it. So it's a case of mixed identity. Raymond +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Visit the Te Papa website http://www.tepapa.govt.nz The email message together with the accompanying attachments may be CONFIDENTIAL. If you have received this message in error, please notify [hidden email] immediately and delete the original message. The views expressed in this message are those of the individual sender, except where the sender specifically states them to be views of Te Papa. Te Papa employs strict virus checking measures and accepts no liability for any loss caused either directly or indirectly by a virus arising from the use of this message or any attached file. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
Hi Raymond,
this is your lucky day, because I did not miss your mail in spite of not being Cc:ed. I wonder whether you like to have speakers talk to you while looking at the audience instead of you. On Fri, 10 Jun 2011, Raymond Coory wrote: > I also found that changing the memory in Edit-Options-Memory & Threads > had no effect. There is a file called jvm.cfg in the Fiji folder, which > updated to the new memory, but Fiji didn't read it, even though it had > just written to it. I created a new file, ImageJ.cfg. Fiji did honour > the memory setting in this file, but won't write to it. So it's a case > of mixed identity. It would be good to know whether your ImageJ was updated to the daily build or some other version rather what is in the Fiji Updater. If that is true, that would explain things. Ciao, Johannes |
Hi Raymond,
On Mon, 20 Jun 2011, Raymond Coory wrote: > > -----Original Message----- > > From: Johannes Schindelin [mailto:[hidden email]] > > Sent: Friday, 10 June 2011 11:40 a.m. > > To: Raymond Coory > > > this is your lucky day, because I did not miss your mail in spite of > > not being Cc:ed. I wonder whether you like to have speakers talk to > > you while looking at the audience instead of you. I actually did not mean to imply that I like private mails better than mails that say "Hi Johannes" but are not addressed to me. I deem it polite to reply to the author of the mail and Cc: the list. > > On Fri, 10 Jun 2011, Raymond Coory wrote: > > > > > I also found that changing the memory in Edit-Options-Memory & > > > Threads had no effect. There is a file called jvm.cfg in the Fiji > > > folder, which updated to the new memory, but Fiji didn't read it, > > > even though it had just written to it. I created a new file, > > > ImageJ.cfg. Fiji did honour the memory setting in this file, but > > > won't write to it. So it's a case of mixed identity. > > > > It would be good to know whether your ImageJ was updated to the daily > > build or some other version rather what is in the Fiji Updater. If > > that is true, that would explain things. > > sorry for not replying earlier. I wanted to check my installation of > Fiji. > > I downloaded a fresh installation file, and updated everything from the > built in updater. The results when attempting to change memory are still > the same as I described. > > I'm on Windows XP (maybe that is the bug...!) The next steps are to verify that - jvm.cfg has been written to in the Fiji.app/ directory, - jvm.cfg contains text corresponding to the memory amount you wanted to set, - fiji, when called from the command line with --console, does not report issues with failures to reserve heap size, and that - fiji, when called from the command line with --console --dry-run, does show the correct memory option (and does not try to override it later on the command line) For information how to run Fiji from the command line, please refer to http://fiji.sc/Debugging_intro#Command_line_debugging Ciao, Johannes |
Free forum by Nabble | Edit this page |