Ticket #486 (closed enhancement: fixed)

Opened 9 years ago

Last modified 8 years ago

Memory Limits Changer

Reported by: gharris Owned by: bdezonia
Priority: minor Milestone: imagej2-b1-initial
Component: Core Version:
Severity: minor Keywords:
Cc: schindelin@… Blocked By:
Blocking: #488

Description

Add API and plugin for changing memory limit

Change History

comment:1 Changed 8 years ago by curtis

  • Milestone changed from biweekly-2011: May-09 to May-20 to imagej-2.0-beta1

comment:2 Changed 8 years ago by curtis

  • Owner changed from curtis to dscho
  • Status changed from new to assigned

comment:3 Changed 8 years ago by curtis

  • Blocking 488 added

comment:4 Changed 8 years ago by dscho

  • Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2

Like #488, bump to beta2

comment:5 Changed 8 years ago by dscho

  • Status changed from assigned to accepted

comment:6 Changed 8 years ago by curtis

  • Milestone changed from imagej-2.0-beta2 to imagej-2.0-beta1

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.

comment:7 Changed 8 years ago by curtis

  • Owner changed from dscho to bdezonia
  • Status changed from accepted to assigned

comment:8 Changed 8 years ago by dscho

  • Cc schindelin@… added

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.

comment:9 Changed 8 years ago by 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.

comment:10 Changed 8 years ago by dscho

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

comment:11 Changed 8 years ago by 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!

comment:12 Changed 8 years ago by bdezonia

In 0ff1796b2d0b4b906778069c09170b96abfd981e 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.

comment:13 Changed 8 years ago by bdezonia

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

comment:14 Changed 8 years ago by curtis

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

comment:15 Changed 8 years ago by bdezonia

Launcher config file ticket hatched: #1079

comment:16 Changed 8 years ago by bdezonia

  • Status changed from assigned to closed
  • Resolution set to fixed

Private class broken out and put in core with commit 1997978287c8fb2880964574b8a2b6816c6e46d9

Last edited 8 years ago by bdezonia (previous) (diff)

comment:17 Changed 8 years ago by bdezonia

In e358f12ffac58d203d7ed655bcba51b4f869d95b 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).

Note: See TracTickets for help on using tickets.