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<http://msdn.microsoft.com/en-us/library/dd183494(VS.85).aspx>. 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. 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
