[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by pclog...@gmail.com: The best poker blog http://poker-blogs-see.blogspot.com Best PokerStars blog http://pokerstars-blogs.blogspot.com Sexy, hot girls imagehttp://china-sexy-girl-images.blogspot.com/ For more information: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by j...@google.com: @bob.whiton: I'm assuming you mean something like this: B.addFooHandler(A); // drop reference to A This is just normal Java memory management -- nothing magic. So if B is still around (because it is, e.g., a widget still attached to the document), then A will still hang around until it's either removed from B's handler manager or B itself is removed and thus collected. For more information: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by bob.whiton: I have a question regarding the com.google.gwt.event.shared.HandlerManager and memory leaks. Let's say that Object A calls addHandler on Object B which contains an instance of HandlerManager. If I destroy Object A, will Object B still have a reference to it? I could categorize that as a leak. Or, must I always call removeHandler? For more information: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by atul.dambalkar: We also have quite a big GWT based application. In our application, we have also seen similar memory issues showing up in FireFox3.6, IE and Chrome4.1 as well. Browsers eventually stopped responding (with CPU more than 70%) after memory reaching up to 1GB (happened with Firefox 3.6, this happened under a load test scenario though). I tried with the above sample code. (Thanks for the code BTW, it's very useful to re-produce the problem quickly) And observed similar memory issue on all the browsers. What I have observed is, on Firefox 3.6 (Windows XP) memory does keep going up all the time but not every time it gets reclaimed/goes down. It goes down very intermittently. I guess that fact might very well be attributed to the way JavaScript engine's garbage collection works or gets kicked-in. I debugged the above code with certain modifications and did see that once cleared from the panel, the new elements do get unattached/removed from browser's DOM(so there may not be memory leaks), but that doesn't really make browser's memory to go down immediately. I am not entirely sure, but if it is due to the fact that perhaps the JavaScript engine's GC is not getting kicked in frequently, is there any way we can hint/force Firefox to run the GC? Or is there any way GWT can provide so that we can force browser to run JavaScript GC. For more information: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using remove me as the subject.
[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by j...@google.com: I'm not aware of any way on most browsers to force a GC. On IE, there's the global CollectGarbage() function, but IE already runs GC too frequently most of the time anyway, so it's not much help. I'm less familiar with Firefox and Safari, but Chrome's GC is generational, so there are several different kinds of collection and compaction, but again I don't believe there's any way to force it. As I noted above, I didn't see the example posted by GlacieredPyro leaking in any obvious way. If you can post a (preferably small) example that causes the browser to run slowly and/or consume an enormous amount of memory, but that doesn't just have an enormous number of objects pinned (i.e., referenced globally or indirectly), I can forward it to the Chrome team so they can have a look. For more information: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using remove me as the subject.
[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by GlacieredPyro: Thanks for the response, I see now that only by running IE in no addon mode will stop the memory from growing, in fact it doesnt get near 30MB. Not that my normal IE installation has anything but the default addons but they seem to make the most trivial application over-use memory. For more information: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by j...@google.com: I've run through this with IE7, IE8, Microsoft's IE JS Leak Detector, and Chrome, and I'm not seeing any evidence of it leaking, on IE at least. On my Vista box, memory grows steadily as I add more items, then mostly recovers as I clear or reset. There is a gentle upward trend in total usage as I do this, but it appears to peak out at around 30MB and no longer grows after that. I'm seeing Chrome's private memory grow without obviously slowing down, but I have to admit to not being too clear on the details of what to expect from its generational GC. I can ping some people on the Chrome team about that, but my guess is that it's going to end up being that it never ran low enough on memory to be worth running a major GC cycle. For more information: http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by GlacieredPyro:
I'm sitting with a situation where either my code is horribly bad and I
should not be in the development industry or there is something wrong.
The following short code sample will leak. In IE 7/8 the odds of getting
memory back are slim to none. FF2 gives some back and chrome(using the dev
tools) releases most if not all. However the Chrome memory footprint using
perfmon private bytes tracking also leaks (so it does not reflect what
the chrome snapshots show).
Could this be a case of insufficient tools to truly track browser memory
usage?
I have after days of research found no answers. The code sample should be
self explanatory :
{{{
public class ARGH implements EntryPoint {
VerticalPanel dpFields = new VerticalPanel();
/**
* This is the entry point method.
*/
public void onModuleLoad() {
HorizontalPanel dp = new HorizontalPanel();
dp.setHeight(120);
RootPanel.get().add(dp);
dp.add(new Button(Add, new ClickHandler() {
public void onClick(ClickEvent evt) {
TextBox t;
for(int i = 0; i 100; i++) {
t = new TextBox();
t.setText(TextField + i);
t.setWidth(200);
dpFields.add(t);
}
}
}));
dp.add(new Button(Clear, new ClickHandler() {
public void onClick(ClickEvent evt) {
dpFields.clear();
}
}));
dp.add(new Button(Reset, new ClickHandler() {
public void onClick(ClickEvent evt) {
dpFields.clear();
RootPanel.get().remove(dpFields);
dpFields = new VerticalPanel();
dpFields.setHeight(200);
RootPanel.get().add(dpFields);
}
}));
dpFields.setHeight(200);
RootPanel.get().add(dpFields);
}
}
}}}
For more information:
http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on DomEventsAndMemoryLeaks in google-web-toolkit
Comment by micahherstand:
If I have classes in Java that reference each other, is this considered
circular referencing and therefore will they never be GC'd? I'm having
big-time memory leaks in FF and Safari without JSNI.
Very stripped down example:
{{{
class Controller{
Model m;
View v;
Controller(Model m, View v){
this.m = m;
this.v = v;
}
//...
}
class View{
Model m;
Controller c;
View(Model m){
this.m = m;
}
setController(Controller c)[
this.c = c;
}
//...
}
class Run{
onModuleLoad(){
Model m = new Model();
View v = new View(m);
Controller c = new Controller(m,v);
v.setController(c);
m = null;
v = null;
c = null //Do Controller and View still exist after this line, since
they reference each other?
}
}
}}}
For more information:
http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
