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 >[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal ---------------------------------------------------------------------------- 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]
