Hi Ankur, Please see replies inlined below. We have found some leaks in our application.One of the greatest leak > that we found in the glasspanel.So for now we are using just a static > glasspanel(From gwt incubator ) and only adding and removing from the > rootpanel.....so for now the problem has been partially fixed at its > leaking only on window close.Still we need to figure out why > glasspanel is leaking.....may be we could found a leak pattern.
If you can produce a repro code snippet that shows the memory leak with the GlassPanel widget, please report it on the GWT Incubator Issue Tracker. GWT Incubator Issue Tracker: http://code.google.com/p/google-web-toolkit-incubator/issues/list > Another possible leak are may be that gwt always creates a new > XMLHTTPRequest object,I tried with a sample appliction both on firefox > and ie....i was just sending a byte array of size 10000 from client to > server and vice versa.In IE memory kept on increasing while in firefox > it was constant.In that sample i tried to reuse the XHR object,the > memory seems to be stable in IE after that.But reusing of XHR seems to > breaking somewhere as that logic cripped when tried with our main > application(may be because in sample there was onl one RPC so it would > hav worked). It seems like you're using GWT RPC, and if so, it also seems like you made some changes to make each RPC call reuse a single XMLHttpRequest object. I'm not sure if GWT RPC does this already by default, but if not, it would definitely be useful to have a repro code snippet here as well to help reproduce the problem here. Also, can I have more information about the types that you're transferring over GWT RPC? Specifically, what do the DTOs that you're sending across the wire contain? I've seen some cases where IE would blow up when sending overly complex DTOs through the wire (deep maps or map values referring the DTO object itself). > Actully there is some problem with the logic how the gwt guys are > clearing the objects in the threadlocal of the JavaDispatchImpl and in > the objects collection of the ObjectTable.java class. I saw the code > they have the logic to clear the objects when they get a free message > from the browser they free up the object from the collection of the > Object table class.We saw the free request is comming for many objects > but it never comback for the callback objects so they are always in > the browser memory.This can be easily seen using jprofiler to profile > the starter application while debugging. May be this problem is only > at debug time....I am thinking to raise it.But OOPHM is not yet > released, so i am not sure if i can raise that issue. I've forwarded this over to John on the GWT team to take an early look in case this is a real issue. Cheers, -Sumit Chandel > > > > regards > ankur > > > > > On Jul 30, 10:10 pm, Sumit Chandel <sumitchan...@google.com> wrote: > > Hi Ankur, > > An application size of 3MB sounds extremely large. Is that gzipped or > > uncompressed? Also, how large is your codebase? > > > > I would imagine that the runAsync feature would have given you a huge > boost > > in reducing the initial download size of your application. You mentioned > > that you broke down the compiled code into multiple script tags - this > > doesn't sound like the result of using the runAsync feature, but rather a > > manual attempt at breaking your code into smaller chunks. Did you use the > > runAsync feature to break down the compiled code into smaller chunks, or > use > > a different approach? > > > > For what it's worth, 700 MB of memory entirely used up by your GWT > > application is an immensely high number. Are you sure that this is only > when > > your application is running in the browser? If so, there are major hot > spots > > where you are either instantiating way too many objects at a time or > leaking > > major amounts of memory as you navigate from one part of the application > to > > the next. > > > > The problem with profiling memory for an Ajax application is that there > > aren't very many robust tools that can be used reliably to find and fix > hot > > spots. For the time being, a rudimentary way of analyzing where memory > usage > > blows up and where memory leaks are occurring would be to monitor your > > system task manager as you navigate through your application. When you > see > > memory usage boost up, you know that you've at least found the > neighbourhood > > of code where the culprit(s) is hiding. > > > > Sorry I can't be of more help, but hopefully this gives you a start to > track > > down where your code is blowing up in memory usage and cut down the > initial > > download size. > > > > Hope that helps, > > -Sumit Chandel > > > > > > > > On Sat, Jul 25, 2009 at 12:22 PM, ankur jain <xs4an...@gmail.com> wrote: > > > hi > > > > > thanks for the reply.But we checked its not due to image bundle.We are > > > using a proper workaround that is mensioned in the issue. > > > > > Actully main problem what we are facind is due to the listeners.And it > > > being very difficut to profile the application in debug mode bcoz most > of > > > the refrences are held by the callback objects. > > > > > I m totally confused. > > > > > regards > > > ankur > > > > > On Thu, Jul 23, 2009 at 3:17 PM, David <david.no...@gmail.com> wrote: > > > > >> Hi Ankur, > > > > >> Could it be that you are using ImageBundle in your application ? We > > >> had similar issues when using ImageBundle, even though we only had a > > >> very small collection of images. > > > > >>http://code.google.com/p/google-web-toolkit/issues/detail?id=3573 > > > > >> David > > > > >> On Wed, Jul 22, 2009 at 7:51 PM, ankur jain<xs4an...@gmail.com> > wrote: > > >> > hi joel...do u hav any suggestion regarding this?? > > > > >> > On Tue, Jul 21, 2009 at 10:57 PM, ankuur <xs4an...@gmail.com> > wrote: > > > > >> >> hi > > > > >> >> We are using the gwt 2.0 code from gwt trunk.And we hav seen a > drastic > > >> >> improvement in the page loading especially in case of IE(6 and > > >> >> 7).Actully breaking the compiled code into the multiple <script> > tag > > >> >> did the trick. > > >> >> But now we are facing the browser memory problem.Actully our total > > >> >> compiled script size(in OBF mode) > > >> >> is more than 3 MB.As we use the application the browser memory > keeps > > >> >> on increasing and sometimes it even reached to the 700MB. > > > > >> >> We tried to profile the application using the javascript tool(like > > >> >> firebug) but of no use because the only provides the performance > > >> >> metrics and not any memory leaks. > > > > >> >> Now we are trying to profile the gwt in the OOPHM mode while > > >> >> debugging.Its helpful and we are able to find some of the problems > in > > >> >> our code.But actully during debugging time most of the refrences > are > > >> >> held by gwt code(mainly by JavaDispatchImpl class and by the static > > >> >> variable in RootPanel i.e. widgetstoDetach) and also all the > asynccall > > >> >> backs are held by RequestBuilder. > > > > >> >> We are assuming that these refrences wont be hold in the compiled > > >> >> mode,because all the classes we see are the debugger classes.But > its > > >> >> making that profiling very tedious as we need to search what > refrences > > >> >> are held by the gwt and where our classes are keeping refrence. > > > > >> >> I dont know we are going through correct approch fpr profiling or > is > > >> >> there any other way so that we can check all the memory leaks and > > >> >> reduce the memory footprint of our application in the browser. > > > > >> >> Any help in this heartly welcomed.And also if we can reduce the > objects > > >> >> (especially all the RPCs callbacks) then actully we can reduce the > > >> >> meomory used during debugging and it might help in mking it faster. > > > > >> >> regards > > >> >> ankur- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
