Bug #3106
openOut of memory while opening all demos, is -Xss5m or SVG the problem?
0%
Description
I'm marking this as having a target milestone of 1.0.0rc1 because
I suspect we should remove -Xss5m from build.xml because it means
we cannot open up very many models. Once that is addressed, the
milestone should be changed to something later.
Under Windows XP with Java 1.5.0_11, Kepler runs out of memory when opening all the demos whereas Ptolemy does not.
It could be that SVG is the issue, or it could be because Kepler
does not do lazy evaluation and thus loads in everything.
To replicate
1) Start Kepler with "ant run-dev", which uses -Xmx512m
2) Help -> Documentation -> Ptolemy Documentation -> Acknowledgements
3) Click on the copyright link at the bottom
4) Click on copyrights in
"Other copyrights about this configuration (may take a moment to run)."
5) Click on about in
"Other information about this configuration."
6) In the "ptolemy/configs/doc/completeDemosPtinyKepler.htm" line, click on
"Open the .htm, .html, .xml and .pdf "
Roughly 25 windows will open and eventually, we get:
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
Under Windows, the task manager says we are using 330Mb of memory,
Editing the run-dev entry in build.xml and removing:
<jvmarg value="-Xss5m"/>
means we get to 580Mb in the task manager and then Kepler hangs with the
CPU Usage at 99%
java -X says that -Xss
-Xss<size> set java thread stack size
Perhaps -Xss should be removed from build.xml?
If I increase the Xmx from 512 to 1024, then the show all demos works,
At the end the amount of memory reported by the Task Manager is
258Mb, with a max of 608Mb
Running the last demo (sr/demo/TrafficLight/TrafficLight.xml) shows
this memory usage under Kepler:
[java] 14471 ms. Memory: 968096K Free: 211261K (22%)
In contrast, doing the same thing with Ptolemy (no SVG), the task
manager reports 142Mb with a max of 142Mb. Running the same demo
reports:
6780 ms. Memory: 117172K Free: 24710K (21%)
Updated by Dan Higgins about 16 years ago
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
Updated by Christopher Brooks about 16 years ago
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.