Memory Limits Changer

[gharris]

Add API and plugin for changing memory limit

[dscho]

Like #488, bump to beta2

[curtis]

Since this ticket blocks #832, which is slated for beta1, this ticket must also be slated for beta1 (or earlier). If there is no time for this, create a new ImageJ launcher feature ticket for beta2, remove this ticket from #832/#488, and add it to that new ticket instead.

[dscho]

The ImageJ launcher (to be integrated into IJ2's code base this week) already interprets the contents of ImageJ.cfg. A typical ImageJ.cfg looks like this:

.
jre\bin\javaw.exe
-Xmx700m -cp ij.jar ij.ImageJ

This file format was invented by the Windows-specific ImageJ1 launcher written in Pascal.

The first line is the current directory (may be relative to the ImageJ root directory). This setting is ignored by the ImageJ launcher.

The second line is the path to the Java executable. Since we try to runtime-link to the libjvm in ImageJ launcher, we ignore that setting, too.

The third line has the Java options. We do interpret these, except the final ij.ImageJ (for obvious reasons).

The ImageJ launcher also sets the Java property ij.dir to the absolute path of the ImageJ launcher (which is supposed to live in the ImageJ root directory). Most likely the memory limit UI needs to look at this property. If need be, we should also look for the ij.executable property which is set by the ImageJ launcher to its own absolute path.

We cannot just put the memory settings into the Preferences because there is no way to set the JVM's heap settings when the JVM has started already (and the ImageJ launcher cannot access the java.util.Preferences before it started up the JVM, and Sun's JVM implementation does not allow to start two JVMs in the same process, even after shutting the first instance down). Catch 22.

[curtis]

Perhaps now would be a good time to rework the cfg format to be more extensible and self-documenting. We could use a key/value pair scheme, for clarity. Something like:

[Configuration]
maxheap = 700m
jvmargs = 

The launcher could look for the '[Configuration]' line or other signature on line one indicating a modern config file. If missing, it would assume the IJ1 format.

Dscho, if you like this, let's file a ticket for it. Or if it's too much work, this could wait till beta2.

[dscho]

The problem is backwarts-compatibility, which is the reason why I did not change the format (but chose to ignore some entries instead).

[curtis]

Exactly, I agree. If we want to update the format, we should add in a versioning scheme. So I will refine my earlier proposal just a bit:

# ImageJ 2.0.0 configuration file, written 2012-03-12 15:27:43
maxheap = 700m
jvmargs =

Then we check whether the first line starts with a hash with the version code, and if not, we assume it's the old ImageJ1 format. Backwards compatibility preserved!

[bdezonia]

In r5116 initial implementation in place. Note that there are some TODOs but basic functionality is in place to allow user to edit memory values in the OptionsMemoryAndThreads dialog and have those changes updated in a new launcher config file format.

TODO

• Break private LauncherParams class out of OptionsMemoryAndThreads. It should be accessible to the launcher class and I'll wait until that integration into IJ12 is done
• There is a method called getCfgFileName() that needs to be updated to find the correct location for the ImageJ.cfg file. This info should come from launcher. Right now I don't have that info. The prefs ij.dir and ij.executable don't exist at runtime at the moment.

[bdezonia]

In r5131 Curtis updated getCfgFileName(). All that is left is to break the private class out to some other location.

[curtis]

Let's also file a separate ticket for updating the configuration file format, as I described above.

[bdezonia]

Launcher config file ticket hatched: #1079

[bdezonia]

Private class broken out and put in core with commit r5135

[bdezonia]

In r5136 updated code so that it only writes an ImageJ.cfg file when the user changes values of the parameters (via OptionsMemoryAndThreads or by calling setMemoryInMB() or setJvmArgs() on a constructed ConfigFileParameters object).