On Thu, Nov 26, 2009 at 12:32 PM, Jim Roskind <j...@chromium.org> wrote: > SUMMARY: > Our handling of bitmap memory may be a fertile ground for saving both > physical and virtual memory. I'm still investigating this, but I wanted to > share my thoughts and very preliminary findings so that other's might chime > in and correct/extend what I'm seeing. > > PRELIMINARY DETAILS and thoughts. > AntonM identified that at least part of the under-counting in the memory > blame utility appeared because of allocations that took place in > CreateDIBSection. That routine creates bitmaps that provide backing store > for the display. The allocations appear to be made in kernel space, even > though the memory is made accessible to users (Chrome) in data returned by > this call.. > a) CreateDIBSection is called in both renderer and in the browser. > Allocation sizes often reflect the height and width of nearly the entire > display device, times 4 (32bits per pixel results in 4 bytes per pixel). On > my machine, this regularly produced allocations in the range of 7+megs. If, > as I was told by Will Chan, we write to one store and then "swap it into > place," then each user (tab? embedded video?) may actually need double this > amount to get their work done. > b) This function is called a LOT. It would appear that we might almost be > thrashing allocation and deallocations at times... but I'm still > investigating. Maybe the debugger was impacting the display... and causing > an evil feedback loop.
While investigating http://code.google.com/p/chromium/issues/detail?id=21921 I observed that on Windows that when the Chrome window is resized, a Skia canvas the size of the entire window is allocated and discarded in order to paint the window background. I don't think this happens during normal repainting operations but is probably one cause of allocation thrashing of these objects. If it would be helpful I can try to reconstruct where this happens but others on this list probably know where it is off the top of their heads. -Ken > c) I'm not completely clear on the lifetime of these large allocations. > They are to some extent reportedly (re: msdn) released when we call > DeleteObject, but it is not immediately clear if they are simply put on a > free list, or decommitted, or fully returned to the OS. I'm also not clear > on the intended lifetime in the context of Chrome/Webkit, renderers, > browsers, and plugins. Can we get away with a more minimal set of such > bitmaps? > d) We also call CreateDIBSection with really small areas. Specifically, we > call it with 1 x 1 pixel areas (there is a comment in the code that we'd > like to ask for a zero size region... but CreateDIBSection reportedly does > not deal with zero very well). I noticed that the tiny bitmap that is > returned is always 64K aligned, and I'm *suspicious* that we've actually > allocated more memory, and I'm sure we've at least fragmented our VM space > with such tiny allocations. > e) There is a possibility that we could more directly manage the large > bitmap storage by calling into CreateDIBSection with pre-allocated areas > (re: mapped objects). Perhaps I'm confused, but I think we're using these > bitmaps to allow renderers to write directly to the graphical context (or to > a secondary backing store that is swapped into place). Perchance such more > direct memory handling could assure we fragment less, and decommit as much > as possible. > In chatting with Will Chan last night, I also heard that JamesR is looking > at the impact on virtual address space of having a multitude of backing > store bitmaps active. Will indicated that when a page has a LOT of videos, > that he was shown that each might require its own bitmap, He said that > JamesR thought this may be playing a role in our out-of-memory problems by > exhausting/fragmenting virtual space. > > Jim > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
