On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke <[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
