This might help a bit, but the heap dump is always during document loading. Once it gets past loading and starts rendering, it is fine 100% of the time.
Ryan Wilson Ryan.Wilson wrote: > > It occurs when someone changes the page they are looking at without > closing the browser. If they close the browser, the jvm that is attached > to the browser closes with the browser. But if they just change the page > they're looking at, any leaks in the applet pollute memory. If someone > were to go back and forth to the leaking applet, the heap eventually > overflows. > > My destroy code was originally as simple as yours, but it didn't prevent > heap overflows. At this point, I've got a destroy method that works fairly > well. It still has a bad habit of not cleaning properly and I've seen it > crash as early as the 6th time to destroy/init the applet. I've noticed > that sometimes the bridgecontext and a bunch of stuff that refered to it > are gone from the heap. Other times, they stick around like before only to > disappear one or two runs later. > > One possible problem that I noticed today is that a thread labelled "Batik > CleanerThread" is throwing a ThreadDeath exception when the applet closes. > I'm thinking that waiting for this thread to close on it's own or for it > to send a "I'm Done" signal before allowing destroy to finish could either > solve or improve my situation. > > I'm still something of a java novice and would appreciate advice on how I > would go about doing this. The API docs for the CleanerThread are not all > that clear. > > Thanks for the response, > Ryan Wilson > > > thomas.deweese wrote: >> >> Hi Ryan, >> >> "Ryan.Wilson" <[EMAIL PROTECTED]> wrote on 09/19/2008 02:14:02 >> PM: >> >>> According to JProbe, most of the stuff left on the heap are objects like >>> GenericText, GenericElementNS, and SVGOM*Element, etc. From what I've >>> traced, almost all of them have a link back to a BridgeContext object >> that >>> is sitting around. I, for the life of me, cannot figure out why it is >> still >>> around. >> >> I'm a little confused about how anything sticks around between >> viewings of the Japplet. Also won't JProbe tell you what the >> live object chain is from a root to the BridgeContext? If the >> BridgeContext is live it will keep lots of other stuff live. >> >> However to answer you question: >> >>> Ryan.Wilson wrote: >> >>> > My question at the moment is what form of cleanup should be performed >> on >>> > batik during the destroy method of an applet? >>> > I have some code implemented already, but it is possible I am missing >>> > something. >> >> In our memory leak test we do the following: >> >> theFrame.remove(theCanvas); >> >> theCanvas.dispose(); >> theFrame.dispose(); >> >> theFrame=null; >> theCanvas=null; >> >> > > -- View this message in context: http://www.nabble.com/Batik-Memory-Leak-in-Applet-tp19536209p19617259.html Sent from the Batik - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
