[kepler-dev] Memory leak.

[Christopher Brooks]

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.

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.

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.

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.

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.

BTW - If I expand the Ptolemy II full configuration, then we end up loading
3468 classes.

_Christopher
--------

    Hi guys,
    
    As everybody else, I was concerned that Kepler's memory consumption, so 
    I ran just kepler startup through -Xrunhprof and looked at the 250M 
    memory report.  I terminated the application "normally" by closing the 
    main window as soon as it appeared.
    
    The answer is... Kepler  is leaking.  Yes, in java you don't have memory 
    leaks you have "in advertant reference retention".
    
    The allocation which is not released is 
    com.microstar.xml.XmlParser.pushURL(XmlParser.java:3169).   This is 
    accounting for 333 leaked char[] totalling 10,919,736 bytes.  This is 
    15% of the allocated memory when I terminated the application.  The 
    number 333 is really interesting it happens to be exactly the same as 
    the number of kar files/actors in the current kepler.  I suspect 
    ActorMetadata or some such is hanging onto a moml parser.
    
    Also, there are 333 byte[] totalling 5,461,200 bytes.  Also in 
    XmlParser.java:4182.  All told about 20% of leaked memory is accounted 
    for by XmlParser.
    
    I tracked this reference retention down to the ptolemy.moml.MoMLParser 
    class.  It has a private member call _parser which is an XmlParser.  
    However, it is not released after parsing is finished.   I added a 
    '_parser = null' at line 1326, right before the return in parse( URL, 
    Reader ).  That definitely plugged it, but I am uncertain the fix is 
    completely safe.  I'm afraid I'll have to defer to The One True Ptolemy 
    Hackers.
    
    There are still a couple of very large allocations but they might be 
    understandable.  The largest 5 allocations account for 8.5M, 17% of 
    memory allocated.  This still seems large since there had been no 
    workflow created.  I might be able to find some time to look into these 
    tomorrow.
    
    Kevin
--------