Kepler

As I remember, the -Xss5m switch was included because setting the stack memory this way was needed to insure that several of our JNI based actors worked properly (the GARP ENM actors that run C code through JNI). So deleting that switch is probably NOT an option.

Also, Kepler now loads actor info only when needed, so it should be roughly equivalent to Ptolemy's lazy evaluations in terms of memory useage.

Another possible culprit for Kepler's memory use is the fact that documentation is included in the moml. This documentation increase the memory used by every actor.

Dan Higgins

I did an experiment under Windows with Java 1.5.0_14 where I changed
-Xmx and -Xss and then used the about: facility to display all the ptolemy
demos.

Below is the output

-Xmx -Xss Windows Mem Windows Peak Mem # of Windows before
running out of memory
512m 5m 362M 365M 36
512m 10m 352M 380M 22
512m 3m 551M 551M 56
1024m 3m 387M 387M 45
1024m 2m 524M 527M 53
1024m 1m 811M 811M 80 (test completed)
1024m not set 807M 808M 80 (test completed)

Note that not all the memory is getting used when we specify -Xss of 2m or
greater.

Note also that there is some sort of non-linear relationship between
-Xmx and -Xss. We get more windows with -Xmx512m -Xss3m than we do
with -Xmx1024m and -Xss3m.

What I think is happening is that this test opens a bunch of models
quickly. -Xss sets the stack size per thread. Each of the models is
probably invoking a number of threads to get images etc.
Thus we are running out of memory.

It could be that this test is somewhat artificial, so I'm downgrading this
bug in priority and moving the milestone.

If people complain about running out of memory, and they are not using
the ENM actors, then they can change -Xss. I think setting -Xss to 5m
might be a little high, but let's wait and see if there are complaints
before changing it.

Original Bugzilla ID was 3106