[chromium-dev] Re: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke s...@google.com wrote: • Switching to another tab in the same window is the only way to get heap usage down significantly (by calling V8's IdleNotification) and even then it takes over a minute of occasional idle-time GC to have a significant effect. Once I get my MemoryPurger functionality checked in, I'd like you to try it and see if it can successfully purge this memory. It loops calling IdleNotification() until that returns true. • Even hiding the tab doesn't bring memory usage down as much. The 'vmmap' tool shows that there's a lot of space allocated to CoreGraphics backing stores, much more than in the single-page case (like 13MB vs 1MB.) I'm not sure if this is for the images on the pages, or snapshots of the pages themselves for the back/forward cache. Safari 4 on Mac has similar behavior. My tool also dumps backing stores. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke s...@google.com wrote: I spent some time this morning looking at Chrome's memory usage (on OS X 10.5.8) while viewing flickr.com. First I simply started at my photo- stream page and hit Reload over and over. Next I tried going through all of my photos one by one. I used the RPRVT column in 'top', and the 'heap' and 'mmap' tools to examine memory usage. Reloading: • Memory usage keeps going up. The renderer starts at about 13MB resident, and goes up a little over 1MB after each reload. I could easily get it up above 50MB. There is some GC going on during the first few reloads, but not after that. Both the malloc and v8 heaps are growing, primarily malloc. • Forcing full GCs brings usage down somewhat, but you have to do it at least five or six times. • Switching to another tab in the same window is the only way to get heap usage down significantly (by calling V8's IdleNotification) and even then it takes over a minute of occasional idle-time GC to have a significant effect. The suspicion is that V8 is holding handles active that are keeping the old DOM alive after refresh, so perhaps we need a way to tell V8 to actively attempt to purge its handles to C++. This would be called after a refresh or a navigation. - James Browsing multiple pages: • Similar memory growth, as above. • Even hiding the tab doesn't bring memory usage down as much. The 'vmmap' tool shows that there's a lot of space allocated to CoreGraphics backing stores, much more than in the single-page case (like 13MB vs 1MB.) I'm not sure if this is for the images on the pages, or snapshots of the pages themselves for the back/forward cache. Safari 4 on Mac has similar behavior. Conclusions: • As already known, V8 isn't collecting enough objects that have handles to big native object trees. • We should call V8::IdleNotification in situations other than a hidden tab. A long-lived tab might go for quite a while without being hidden in this way: the user might activate another app, hide Chrome itself, or just use multiple windows instead of tabs. • There may be an opportunity in WebCore to toss out image backing stores more aggressively. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke s...@google.com wrote: I spent some time this morning looking at Chrome's memory usage (on OS X 10.5.8) while viewing flickr.com. First I simply started at my photo- stream page and hit Reload over and over. Next I tried going through all of my photos one by one. I used the RPRVT column in 'top', and the 'heap' and 'mmap' tools to examine memory usage. Reloading: • Memory usage keeps going up. The renderer starts at about 13MB resident, and goes up a little over 1MB after each reload. I could easily get it up above 50MB. There is some GC going on during the first few reloads, but not after that. Both the malloc and v8 heaps are growing, primarily malloc. • Forcing full GCs brings usage down somewhat, but you have to do it at least five or six times. • Switching to another tab in the same window is the only way to get heap usage down significantly (by calling V8's IdleNotification) and even then it takes over a minute of occasional idle-time GC to have a significant effect. Browsing multiple pages: • Similar memory growth, as above. • Even hiding the tab doesn't bring memory usage down as much. The 'vmmap' tool shows that there's a lot of space allocated to CoreGraphics backing stores, much more than in the single-page case (like 13MB vs 1MB.) I'm not sure if this is for the images on the pages, or snapshots of the pages themselves for the back/forward cache. Safari 4 on Mac has similar behavior. Conclusions: • As already known, V8 isn't collecting enough objects that have handles to big native object trees. I disagree with this conclusion. V8 doesn't know anything about the large object trees. I think we (webkit) need to figure out how to clean up these trees independently. Since you said you're just reloading constantly, it could be that we're not cleaning up on page transitions. Alternatively, we could rework the bindings to allow cleanup of memory, while leaving only a small stub C++ wrapper. Webkit could cleanup it's huge object trees independent of GC this way. The bindings would need to be modified to deal with this case and error out (or re-wrap) appropriately. • We should call V8::IdleNotification in situations other than a hidden tab. A long-lived tab might go for quite a while without being hidden in this way: the user might activate another app, hide Chrome itself, or just use multiple windows instead of tabs. We should try to avoid this. The V8 team has (rightfully) resisited hooks to allows the application to call gc() directly, because once you do that, invariably, some smart programmer decides to call gc() all the time!! :-) V8IdleNotification is basically a route to get at gc(). Let's not abuse it. If we're having problems getting memory cleaned up we should figure out: - where did the memory go in the first place - how to clean up incrementally We definitely don't want to grow too dependent on gc() to keep memory low. • There may be an opportunity in WebCore to toss out image backing stores more aggressively. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:57 AM, Mike Belshe mbel...@google.com wrote: • We should call V8::IdleNotification in situations other than a hidden tab. A long-lived tab might go for quite a while without being hidden in this way: the user might activate another app, hide Chrome itself, or just use multiple windows instead of tabs. We should try to avoid this. The V8 team has (rightfully) resisited hooks to allows the application to call gc() directly, because once you do that, invariably, some smart programmer decides to call gc() all the time!! :-) V8IdleNotification is basically a route to get at gc(). Let's not abuse it. I don't think it's unfair to call IdleNotification() on the foreground tab if e.g. the user has not done anything with it for five or ten minutes. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
