1.16 KB, text/html
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: Creating a large dynamic creately table into an iframe leaks till the end of WC (I dont know where that goes to, but it sounds pretty severe). I created 300 rows with 4 columns in an iframe and Mozilla leaked 20Megs of memory. I still use 1.3.1 because it is much more sane DOMwise. From 1.4.0, the leak goes bananas to aroung(d) 40Megs of memory. It is a severe fact that You need more capable plugs. DOM has been getting worse since 1.3.1, dont know what is up that? By the way I am too lazy to report another bug for it but the events got very slow right from 1.4.0. A security check for each event handling must be in place. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: Leak goes uber WC. Expected Results: It should use at least a reasonable amount of memory liek 4megs from IE.
No testcase, no steps to reproduce, no indication of why you think this is a memory leak -- marking invalid. Please feel free to reopen after providing some of the above information so that this bug could actually be addressed.
Nah, no testcases will be provided. It may stay invalid. Where is the new DOM redesign you guys have been talking about? All you have patched pipes and a ,still, oil burning diesel engine. The rpm of the engine is going down in every release. I admit it you guys are seriosly understaffed. But hey keep up the good work, at least the release number is moving.
> Nah, no testcases will be provided. The problem with that is that if I can't reproduce the bug with code I create (and I can't), then I have to read your mind to attempt to do anything about it. Unfortunately I am not a mind reader. > Where is the new DOM redesign you guys have been talking about? There has been no DOM redesign being talked about that I'm aware of... Thank you for the insults and the waste of everyone's time.
No offense but I was not insulting anybody. I have numeruous times indicated before that you guys are doing a tremendous job considering this is a voluntary effort. I thought there was a Gecko 2.0 in works, and in parallel there would have been a talk of a new DOM design. It is not an insult if I call it a patched pipe, it is the hard working truth. Anyhow, I am sorry if I have insulted you in anyway. So, is there a design problem in Mozilla DOM that makes things working not very well?
What is an insult, sir, is telling us that we have a problem, refusing to help in any way in finding what the problem is, and then saying that the code is of poor quality. Criticizing code without showing any evidence that the criticism is well founded is an insult. I am not aware of anyone else finding the bug you are referring to, so as far as everyone else is concerned, it is good, working code.
OK, very good then.
Created attachment 137202 [details] Why this simple dynamic table takes 25 Megs of Memory Why this simple dynamic table takes 25 Megs of Memory
Um, are we talking memory usage here, or memory leakage? If you load the page 5 times after eachother, does Mozilla's memory usage go up as much (or at all) with every consecutive load?
John, it is a memory usage problem as well as memory leak. I will put couple of more test cases demonstrating the problem in detail when I have time this weekend.
Reporter, how about those leak testcases?
Sorry , I am too busy. How about trying to find out why that much of memory usage is necessary? Note: By the way, If I have time I will post tons of DOM bugs which made us stop supporting mozilla all together. Everything was fine with mozilla 1.3.1 using NT and win2K. When we used an XP last week, we stopped it all together. We spent tons of man power and money for a working mozilla 1.3.1 version of our platform(a very complex DOM application), but it just didnt work at all on XP. Mozilla is way unpredictable, and we dont have neither time or money to go through all the operating systems out there. But I will submit those bugs when I have time. good luck.
I just did a quick calculation of the minimal amount of memory we could possibly be using on that testcase (using the bloat stats stuff to get base sizes for objects and then manually computing subclass sizes). We are creating 3500 rows, 5 cells each, 11 char textnode in each cell. That means: 3500 <tr> objects (at least 32 bytes each, if the 28 bytes for generic element includes the vtable pointers) 17500 <td> objects (at least 36 bytes each, similar constraint) 17500 textnodes (28 bytes each, plus 11 bytes for the text) 3500 table row layout objects (at least 72 bytes each, given the 44 for an nsFrame) 17500 table cell layout objects (at least 76 bytes each) 17500 celldata objects (4 bytes each) 17500 block layout objects (at least 64 bytes each) 52500 line box objects (since each block has three lines; at least 48 bytes each) 52500 text layout objects (one bit of text per line; 64 bytes each) 38500 XPCWrappedNative objects (one per row, cell, textnode since each is accessed via DOM; 52 bytes each) Total for that: 12 megabytes or so. That's about half of the total memory increase I am seeing, but maybe I'm forgetting some other obvious places where memory would be used that the bloat log would not show? Is the XPCWrappedNative size correct? It'd need to be _way_ off for it to account for the extra 12 megs. It's also possible that the extra memory is allocated off the presshell arena as a temporary during reflow then released back to the allocator, which can't release it to the OS. So it looks like we're using way more ram than we really are. See bug 130157. I;m not sure how heavily we use the arenas during reflow... As for the rest, just telling us that something broke doesn't help us or you. :( I've seen many sites that were very complicated and relied on various bugs break when those bugs got fixed; the alternatives are either to not fix bugs or for people to let us know when changes we make break something....
One thing I have to wonder is whether we can garbage-collect some of the XPCWrappedNatives... or do we?
Almost forgot. Also 38500 JSObjects, which are kept from going away by the rooting on the document. Looks like at least 20 bytes each, which is another 770k or so...
A JSObject is 8 bytes of GC-thing, 1 byte of GC-thing flag, minimum 20 net (24 gross) malloc'd slots storage, and some share in a JSScope and its entrained memory. The JSRuntime.propertyTree stuff aggressively shares JSScopeProperty structs, so you shouldn't see much memory tied up there. Spacetrace or just a couple of trace-malloc dumps seem like the tools to use here. /be
That involves having a trace-malloc or spacetrace enabled build, no? Or are those on by default in debug builds?
http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/README#35 is still valid, I think. Spacetrace is a separate app (a loopback http server, yet), and running it and mozilla on the same system requires a ton of memory to perform well (we have a 1GB system at Mozilla Headquarters set aside for space-tracing -- dbaron may know more). /be
But just --enable-trace-malloc and you can use the scriptable JS methods implemented around http://lxr.mozilla.org/mozilla/source/dom/src/base/nsJSEnvironment.cpp#1644. With TraceMallocDumpAllocations called from JS, you could get a before vs. after dump, then do some sorting and comm(1)-based set differencing. /be
>As for the rest, just telling us that something broke doesn't help us or you. >:( I've seen many sites that were very complicated and relied on various bugs >break when those bugs got fixed; the alternatives are either to not fix bugs or >for people to let us know when changes we make break something.... I know Boris, you are absolutely right; but days are only 24 hours, and we have tons of stuff on our table. I will submit those when I have time, I promise. In any case, we will need mozilla again in a near future. For now, I have to stick with our own priorities. On the other hand, glad to see you guys hammering down the memory usage phenomenan.
Re comment 18: I also wrote a perl script, mozilla/tools/trace-malloc/diffbloatdump.pl to show the differences (in tree form) between two allocation dumps.
Could this be the scroll buffer of the IFRAME? How is the scroll buffer of the IFRAME is handled as oppose to the normal browser frame's scroll buffer when dynamic elements are added to the content? It really eats up extra ordinary amount of memory for just 3500 rows. I think it is not DOM related. It gotto be with something else like scroll buffer(may be). note: I made assumptions, hadnt looked at the code. cc'ing Robert.
That makes no sense. Anyway, the leak testcases promised never appeared. Marking bug invalid. Please reopen when you attach the testcases.
Okey so dynamicaly creating 3500 rows using 25 Megs of Memory is a perfectly valid behavior then. Very well, no more comments.