The sample code I provided only produces the memory leak in hosted mode. I am however experiencing a memory leak in my real world app, I just haven't written any sample code the demonstrates it in IE (the only browser we currently build for.)
On Sep 3, 10:52 am, Chris Conroy <[email protected]> wrote: > @chrisr: > > Are you seeing a leak in the Development Mode JVM, or are you observing it > in the browser? > > > > On Fri, Sep 3, 2010 at 8:12 AM, Joel Webber <[email protected]> wrote: > > Sorry I didn't follow up earlier (this should have showed up in my > > inbox, but didn't for some reason...). > > > @chrisr: > > It is at least remotely possible that this could have leaked in 1.5.4, > > but I'm not aware of any memory-leak fixes as recently as that. The > > architecture that guards against leaks is sound, and hasn't changed > > significantly since 1.0. There were a couple of bug fixes for little > > pieces of Javascript that were triggering leaks (notably in the > > RequestBuilder code, which this doesn't exercise), but that was some > > time ago. As for the dev mode leak, I've asked one of my team members > > who's working on optimizing dev mode to take a look at that. > > > @Marcos: > > I wish I could do more to help with memory leaks in SmartGWT, but > > that's way beyond the knowledge of anyone on our team. SmartGWT's a > > wrapper around a huge Javascript library that, from your earlier post, > > appears to require destroy() calls on widgets as part of its memory- > > leak strategy (IIUC). That strategy's rife with problems and very hard > > for users to get right in practice (I've tried it in other frameworks, > > and always found myself squashing leaks ad infinitum). Do the SmartGWT > > tools not provide some mechanism for tracing and finding leaks? > > > On Aug 30, 9:10 am, chrisr <[email protected]> wrote: > > > This may be a valid solution, however its not an ideal one, as this > > > application is already significantly large, and its not going to be > > > easy to refactor all of the existing code to work this way. It will > > > be easy to keep this in mind while going forward, however. > > > > As I said above, I was trying to reproduce the way a lot of the code > > > I'm working with has been written. Also, while I thought this was > > > reproducing the situation we are seeing in our live app (using GWT > > > 1.5.4) it turns out this only produces the memory leak in development > > > mode using the most recent GWT. I will have to see if this produces a > > > leak when compiled using 1.5.4. If not then I'll probably need to > > > find a new simple case that reproduces the leak we're seeing. > > > > On Aug 28, 11:48 am, Michael W <[email protected]> wrote: > > > > > I doubt following code causing the memory leak. > > > > In reloadRight method, you create and assign new DecoratedTabPanel() > > > > to tabPanel every time. > > > > > protected void reloadRight(){ > > > > ++rightPanelCount; > > > > rPanel.clear(); > > > > > tabPanel = new DecoratedTabPanel(); > > > > > You may reuse existing tabPanel instead of create new one. > > > > > On Aug 27, 4:21 pm, chrisr <[email protected]> wrote: > > > > > > Hi Joel, i appreciate your help. > > > > > > I was running in development mode and it appears that this memory > > > > > bloat goes away when not using development mode. > > > > > We have been developing our application using older GWT (1.5.4 I > > > > > belive) so I'm used to using the old hosted mode. I didn't realize > > > > > the in browser development mode might have this side effect. > > > > > > The goal of this was to reproduce a memory leak that we have in our > > > > > application (when compiled, of course) using as simple a case as > > > > > possible, in the newest version of GWT, if possible. I erroneously > > > > > thought this was accomplishing that. > > > > > > Does the fact that this growth occurs in development mode suggest > > > > > anything about why I might see similar growth in a compiled GWT 1.5.4 > > > > > application? > > > > > > On Aug 27, 12:52 pm, Joel Webber <[email protected]> wrote: > > > > > > > Hmm... I've tried to reproduce this on IE7 and IE8 (both quirks & > > > > > > standards), to no avail. I doubt it's anything in the outer HTML > > file, > > > > > > but just in case, here's what I used: > > > > > > > <!DOCTYPE HTML> > > > > > > <html> > > > > > > <head> > > > > > > <title>Hello</title> > > > > > > <script type="text/javascript" language="javascript" > > src="hello/ > > > > > > hello.nocache.js"></script> > > > > > > </head> > > > > > > <body> > > > > > > <div id='container'></div> > > > > > > </body> > > > > > > </html> > > > > > > > The initial calls to getSomeText() were causing a huge number of > > slow- > > > > > > script warnings on IE, so I was only able to run through a few > > > > > > iterations. I then dropped the count by a factor of 10 to get the > > SSWs > > > > > > under control, and the memory usage appears quite stable after a > > > > > > couple of hundred clicks. (~30MB). Can you think of anything else > > that > > > > > > might be different in your setup? > > > > > > > On 27 août, 08:20, chrisr <[email protected]> wrote: > > > > > > > > Sorry for posting this twice. If a moderator wants to/can remove > > the > > > > > > > duplicate go ahead. > > > > > > > > On Aug 25, 2:56 pm, chrisr <[email protected]> > > wrote: > > > > > > > > > I created a simple application in an attempt to reproduce a > > memory > > > > > > > > leak issue in our decently large GWT application. > > > > > > > > > This test application basically contains a split panel with a > > button > > > > > > > > on the left, and a tab panel full of large blocks of text on > > the > > > > > > > > right. > > > > > > > > Clicking the reload button fires the reloadRight method, and > > does a > > > > > > > > panel.clear() to remove the old tab panel and a panel.add() to > > add a > > > > > > > > new tab panel to the right panel. Doing this repeatedly causes > > memory > > > > > > > > consumption to increase without bounds. > > > > > > > > > For example, on the initial load IE7 uses around 35 MB. 125 > > clicks > > > > > > > > later its using nearly 1.5GB. > > > > > > > > > Is this example doing something in a fundamentally incorrect > > way? > > > > > > > > How can I keep memory usage from exploding like this? > > > > > > > > > /* Example Below */ > > > > > > > > > package com.example.myproject.client; > > > > > > > > > import com.google.gwt.core.client.EntryPoint; > > > > > > > > import com.google.gwt.event.dom.client.ClickEvent; > > > > > > > > import com.google.gwt.event.dom.client.ClickHandler; > > > > > > > > import com.google.gwt.user.client.ui.Button; > > > > > > > > import com.google.gwt.user.client.ui.DecoratedTabPanel; > > > > > > > > import com.google.gwt.user.client.ui.DecoratorPanel; > > > > > > > > import com.google.gwt.user.client.ui.HTML; > > > > > > > > import com.google.gwt.user.client.ui.HTMLPanel; > > > > > > > > import com.google.gwt.user.client.ui.HorizontalSplitPanel; > > > > > > > > import com.google.gwt.user.client.ui.RootPanel; > > > > > > > > > /** > > > > > > > > * Entry point classes define <code>onModuleLoad()</code>. > > > > > > > > */ > > > > > > > > public class TestApplication01 implements EntryPoint { > > > > > > > > > /** > > > > > > > > * This is the entry point method. > > > > > > > > */ > > > > > > > > public void onModuleLoad() { > > > > > > > > RootPanel.get("container").add( new MainPanel() > > ); > > > > > > > > } > > > > > > > > > private class MainPanel extends DecoratorPanel{ > > > > > > > > > private HorizontalSplitPanel hsp; > > > > > > > > private HTMLPanel lPanel; > > > > > > > > private HTMLPanel rPanel; > > > > > > > > private DecoratedTabPanel tabPanel; > > > > > > > > int rightPanelCount = 0; > > > > > > > > > public MainPanel(){ > > > > > > > > hsp = new HorizontalSplitPanel(); > > > > > > > > hsp.setSplitPosition("25%"); > > > > > > > > hsp.setSize("800px", "400px"); > > > > > > > > lPanel = new HTMLPanel("<div > > id=\"reloadButton\"/>"); > > > > > > > > > rPanel = new HTMLPanel("<div > > id=\"right-panel-contents\"/>"); > > > > > > > > Button reloadButton = new > > ReloadButton(this); > > > > > > > > reloadButton.setVisible(true); > > > > > > > > lPanel.add( reloadButton, > > "reloadButton" ); > > > > > > > > hsp.setLeftWidget(lPanel); > > > > > > > > hsp.setRightWidget(rPanel); > > > > > > > > this.add( hsp ); > > > > > > > > reloadRight(); > > > > > > > > } > > > > > > > > > char[] chars = new char[] {' ',' ',' ', ' ', ' > > ', > > > > > > > > 'a','b','c','d','e','f','g','h','i','j','k','l','m', > > > 'n','o','p','q','r','s','t','u','v','w','x','y','z' }; > > > > > > > > > private String getSomeText(int length){ > > > > > > > > StringBuffer sb = new > > StringBuffer(length); > > > > > > > > for ( int i=0; i<length; ++i ){ > > > > > > > > > sb.append( chars[ > > (int)Math.round(Math.random()*(chars.length-1)) ]); > > > > > > > > if ( i>0 && i % 60 == 0 ) > > > > > > > > sb.append("<br>"); > > > > > > > > } > > > > > > > > return sb.toString(); > > > > > > > > } > > > > > > > > > protected void reloadRight(){ > > > > > > > > ++rightPanelCount; > > > > > > > > rPanel.clear(); > > > > > > > > > tabPanel = new DecoratedTabPanel(); > > > > > > > > tabPanel.setWidth("400px"); > > > > > > > > tabPanel.setAnimationEnabled(true); > > > > > > > > > String text = "Load count = > > "+rightPanelCount; > > > > > > > > > tabPanel.add( new > > HTML(text+"<br>"+getSomeText((int) > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
