[kepler-dev] Memory leak.

[Richard van der Laan]

Hi,

I have embedded the Ptolemy kernel in an OSGi service. This service
acts as an container for deployed model graphs and can dynamically associate
actor behavior with service behavior. In our situation, multiple parsed
models
(around 30) can coexist.

Before a new model is parsed, I call reset() on MoMLParser. This avoids
incremental model parsing, that would otherwise create dependencies across
seperate deployed models. Maybe this is related to the memory leak
mentioned by Kevin.

A few weeks ago I spent some time profiling our system. Regarding the current
subject, I discovered a memory leak in one of the alternative paths of the
MoMLParser:

During parsing, the MoMLParser can throw a XMLException if the file content
is invalid and can throw a ClassNotFoundException if some classes could not
be resolved. In case one of these exceptions is thrown, the entities
contained
by the partial constructed graph are still added to the workspace.

In my opinion the MoMLParser should in that case undo the performed
workspace actions.


Best wishes,

Richard van der Laan, Luminis
TheWeb: http://www.luminis.nl
LOSS  : https://opensource.luminis.net

-----Original Message-----
Kevin:

You are right...

When a parser is used to open a model, the model itself acquires an
instance of ParserAttribute, which contains a reference to the parser.
Thus, as long as there is an active reference to the model, there
will be a reference to the parser.  We could perhaps change ParserAttribute
to have a weak reference to the parser.

I think the real issue is that the model should pass out of scope,
and maybe it is not being passed out of scope.

Moreover, references to models may persist longer than they should...
Although I think we made an effort to make sure all references to the
model were weak references, I'm not sure we did it exactly right...
Unfortunately, in Java, it seems you can't actually force a weak
reference to dissociate...

Edward


At 01:34 PM 12/21/2005 -0600, Kevin Ruland wrote:

>Edward,
>
>I don't fully understand the situation and defer to you or Christopher for
>greater details.   Perhaps there is something in the Kepler code which is
>holding onto a MoMLParser too long.
>
>In kepler there is this code in ActorMetadata.ActorMetadata( InputStream
>moml):
>
>{
>
>MoMLParser parser = new MoMLParser();
>NamedObj obj = parser.parse( null, moml );
>
>...
>
>}
>
>So in theory the parser should be local and go out of scope.
>
>But in the MoMLParser.parse( URL, Reader ) method, it looks like this is
>being held onto.  parser returns a variable called _topLevel.  But there
>is code in the parse() method which assigns this (MoMLParser) to an
>attribute of _topLevel called "_parser".  I believe this is where the
>reference to the MoMLParser is being retained.
>
>Kevin
>
>Edward A. Lee wrote:
>
>>At 12:29 AM 12/21/2005 -0800, Christopher Brooks wrote:
>>
>>>Yep, this looks like a leak of some sort.
>>>
>>>In MoMLParser, _parser is declared as:
>>>     private XmlParser _parser = new XmlParser();
>>
>>
>>
>>I'm confused... Wouldn't the leak then actually be
>>in the creation of multiple instances of MoMLParser without
>>deleting them?
>
>------------
>Edward A. Lee
>Professor, Chair of the EE Division, Associate Chair of EECS
>231 Cory Hall, UC Berkeley, Berkeley, CA 94720
>phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
>eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal


----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu