[kepler-dev] Memory leak.

Kevin Ruland kruland at ku.edu
Wed Dec 21 04:38:42 PST 2005


Christopher,

Christopher Brooks wrote:

>Hi Kevin,
>
>Yep, this looks like a leak of some sort.
>
>In MoMLParser, _parser is declared as:
>    private XmlParser _parser = new XmlParser();
>
>I'm not sure if setting _parser to null in 1326 of
>MoMLParser.parse(URL, Reader) is safe or not.  What happens the next
>time this method is called with the same MoMLParser?  _parser is null
>and we will crash.  I'm not sure if there is much state in XmlParser,
>so creating and destroying _parser each time could be ok.
>  
>
I was just testing a hypothesis and didn't want to spend a whole lot of 
time fixing it correctly.  XmlParser (or it's delegate, I don't recall 
which) does allocate some stuff including a fairly sizeable char[], but 
extra work is much better than a 15M leak, imo.

I've thought of a few fixes.

One way to fix it would be to wrap the _parser member and the methods 
which use it directly in an inner class of MoMLParser.  The inner class' 
members would still have access to the containing class's private data 
so there wouldn't have to be a bunch of setters to much up the 
interface.  Then it might be easier to see where the object needs to be 
created.

Another is to allocate the _parser variable in the parse(URL,String) 
method.  Seems like a reasonable thing to do.  But it doesn't look all 
that pretty to have a member variable be allocated/deallocated all the time.

Another is to declare _parser as function local, then pass it into all 
the methods that use it.  This would result in a pretty ugly private 
api, but would certainly make the use of _parser more explicit.

>It would be interesting to see if we can fix the leak, but it might be
>better to use a different parser.  We are currently using Aelfred,
>which is fairly old.
>  
>

The second reason I didn't want to spend a whole lot of time fixing it.  
I pointed out just a little while ago that the microstar parser was 
fingered as a possible performance problem.  BTW - that analysis was 
inconclusive, it only stated that the parser consumed a lot of time - 
but we know it's used a lot too.  I suggest before gutting it (it's a 
piece of work, I know because I tried to implement MoMLParser as a SAX 
ContentHandler and couldn't accomplish it), you actually pit two parsers 
in a simple head to head parsing task.

>BTW - I looked at the start up of Kepler, and when I insert -verbose
>in the command line it looks like we are loading 4267 classes.
>When I start up Ptolemy II vergil, we are loading 2008 classes.
>I think part of the reason for the difference is that Ptolemy II loads
>actor classes lazily whereas Kepler loads everything right away.
>  
>
I noticed this too.  Before an actor is dragged onto the canvas, all 
that's really needed is: the name, the folder, and the little icon.  
Since we have a database behind Kepler, we should be able to cache all 
this stuff in there without parsing moml at all.  It's definitely worth 
looking at, and also would greatly speed up startup.

>The reason Ptolemy II does this is so that the configuration can have
>actors in it that don't necessarily work on the local machine because
>the local machine is missing libraries.  For example, not all machines
>have Java3D installed, yet the full vergil configuration includes 
>the GR domain actors, which use Java3D.  Users without Java3D only
>notice a problem if they open a model that uses the GR domain actors
>or if they open the branch of the actor hierarchy that has GR domain
>actors.
>
>  
>
Very good reason.  Matt wants Kepler to be usable as a f.e. to 
distributed workflows. 

>Lazy loading also makes it easier to use WebStart and pull over only
>the jar files that we need to run a particular model.
>
>The downside of the Ptolemy lazy loading is that searching the actors
>is impossible without fulling loading them.
>  
>

Any changes which implement lazy loading of the actors will have to wait 
until Chad comes back.  That area of the code seems like a mine field.

Kevin


More information about the Kepler-dev mailing list