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-tp19536209p19616271.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]
