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
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
