Re: Profiling memory usage for large gwt application
Sumit Chandel wrote: 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). Sounds reminiscent of issue 3577. http://code.google.com/p/google-web-toolkit/issues/detail?id=3577 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Profiling memory usage for large gwt application
Ankur, If I understand correctly, you're describing two separate issues here: 1. The incubator GlassPanel appears to be causing a leak. How did you detect this? 2. RPC is causing IE's memory usage to increase over time. Are we talking about OOPHM or web mode in both of these cases? If it's OOPHM, I'll have to defer to others on how Java-JS references are accounted for in the plugin. If it's in web mode, then it would be useful to have simple test cases that reproduces these issues. Given some of the hackery in the GlassPanel code, I can imagine that a memory leak might have slipped through. RPC would surprise me, though, as we try to carefully clean up al references that could create memory-leak cycles involving the XHR object in the RequestBuilder code. But stranger things have happened :) Cheers, joel. On Thu, Aug 6, 2009 at 5:31 PM, Sumit Chandel sumitchan...@google.comwrote: 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 iei was just sending a byte array of size 1 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 timeI 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
Re: Profiling memory usage for large gwt application
hi Actully we have built the code from the gwt trunk.so the breaking of code is not done manuallyit is one of the feature of gwt 2.0. Its true that only our application is running on the browser and the memory has reached upto 700MB.and out codebase really huge with lots of RPCs,DTOs and many custom components.I am not sure about the exact size of codebase...will update u soon with it. 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. Another possible leak are may be that gwt always creates a new XMLHTTPRequest object,I tried with a sample appliction both on firefox and iei was just sending a byte array of size 1 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). There is actully some caching problem with ie..setting no-cache header is also not helping out. We didnt tried out runasync as such but we plan to do it.not now some time later. 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 timeI am thinking to raise it.But OOPHM is not yet released, so i am not sure if i can raise that issue. 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 jainxs4an...@gmail.com wrote: hi joel...do u hav any suggestion
Re: Profiling memory usage for large gwt application
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 jainxs4an...@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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Profiling memory usage for large gwt application
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 jainxs4an...@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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Profiling memory usage for large gwt application
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 jainxs4an...@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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Profiling memory usage for large gwt application
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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
