Hi Richard,
I had a look at this and I'm having a hard time reproducing it.
That doesn't mean it is not a bug, it just means I can't reproduce
it. :-)
Stephen Neuendorffer suspects that what you report is indeed a bug,
but until I can reproduce it, I can't fix it.
What I did was create
ptII/ptolemy/actor/lib/string/test/StringCompare.tcl
which parses
ptII/ptolemy/actor/lib/string/test/auto/StringCompare.xml
and then executes it twice. I'm not seeing the rate variables
changing with each run, but I'm probably not doing something
that you are doing.
One twist is that I created
ptII/ptolemy/actor/lib/string/test/SDFTestScheduler.java
which extends SDFScheduler and has a method:
public List getRateVariables() {
return _rateVariables;
}
I explicitly set the scheduler to an instance of SDFTestScheduler.java
The tcl code in StringCompare.tcl looks like this:
test StringCompare-1.1 {test PortParameter memory leak} {
set workspace [java::new ptolemy.kernel.util.Workspace "pubWS"]
set parser [java::new ptolemy.moml.MoMLParser $workspace]
$parser setMoMLFilters [java::null]
$parser addMoMLFilters \
[java::call ptolemy.moml.filter.BackwardCompatibility allFilters]
$parser addMoMLFilter [java::new \
ptolemy.moml.filter.RemoveGraphicalClasses]
set url [[java::new java.io.File "auto/StringCompare.xml"] toURL]
$parser purgeModelRecord $url
set model [java::cast ptolemy.actor.TypedCompositeActor \
[$parser {parse java.net.URL java.net.URL} \
[java::null] $url]]
set director [java::cast ptolemy.domains.sdf.kernel.SDFDirector [$model
getDirector]]
set scheduler [java::new ptolemy.actor.lib.string.test.SDFTestScheduler \
$director "MySDFTestScheduler"]
$director setScheduler $scheduler
#set scheduler [java::cast ptolemy.domains.sdf.kernel.SDFScheduler
[$director getScheduler]]
set manager [java::new ptolemy.actor.Manager $workspace "MyManager"]
$model setManager $manager
$manager execute
set rateVariables [$scheduler getRateVariables]
set r1 [listToNames $rateVariables]
$manager execute
set rateVariables [$scheduler getRateVariables]
set r2 [listToNames $rateVariables]
list $r1 $r2
} {{tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate} {tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate tokenConsumptionRate
tokenConsumptionRate tokenConsumptionRate}}
If SDFScheduler._rateVariables was growing, I would expect its length
to grow.
The above files are checked in to cvs, so you could check them out,
see http://chess.eecs.berkeley.edu/ptexternal
I tried the above test under the cvs devel version of Ptolemy II
and under Ptolemy II 6.0.2 and got the same results: the _rateVariables
variable did not change in size.
So, what am I doing wrong? I'm not sure about your ModelManager
and if it is the same as ptolemy.actor.manager.
Do you have a small test case that illustrates the growth problem?
Also, what version of Ptolemy are you using?
Thanks,
_Christopher
> Hi ptolemy hackers,
>
> In our situation we have embedded part of the Ptolemy kernel in our
> application, parsing models using an instantiated MoMLParser and
> executing models using a ModelManager. We have been doing this for
> some time for many constructed models, without any problems. Last week
> I constructed a SDF model which includes a StringCompare actor. When
> repeatedly executing the model, reusing the objectgraph constructed
> during model parsing, I ran into some memory problems.
>
> We started profiling our application and found out that memory use
> increases during every new model execution. However this is only the
> case when executing the SDF model that includes the StringCompare
> actor. Pin-pointing the problem further We found out that the
> PortParameters of the StringCompare actor (first/second string) are
> stored as rate variables (linkedlist) in the SDFScheduler. After every
> execution of the model graph, the size of the rate variables list
> increases by new added PortParameters. Note that before each model
> execution the model manager is properly initialized and the
> initialize()/preinitialize() methods of actors are invoked.
>
> Because the model is initialized before execution I would expect that
> the rate variables list of the SDFScheduler is cleared during
> initialization (or during the wrapup of the last execution). However
> this is not the case. Scanning the sourcecode of the SDFScheduler and
> base classes I found no trace of code that properly clears the rate
> variables list.
>
> In order to make sure that our problem is caused by the memory use of
> the SDFScheduler we subclassed the SDFScheduler and overrrided the
> preinitialize() method by this code:
>
> public void preinitialize() throws IllegalActionException {
> try {
> getScheduler().setContainer(null);
> new SDFScheduler(this, uniqueName("Scheduler"));
> } catch (NameDuplicationException e) {
> throw new IllegalActionException(e.getMessage());
> }
> super.preinitialize();
> }
>
> This code removes the current scheduler from the model container and
> instantiates a new SDFScheduler with a clean rate variables list. This
> patch solves our memory problem.
>
> I don't know if the SDFDirector and SDFScheduler has been designed
> with object reuse in mind, many actor classes do because they include
> proper initialize and wrapup code.
>
> Kind regards,
>
> Richard van der Laan, luminis
> TheWeb: http://www.luminis.nl
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
