On 11/25/13 8:15 PM, Bas Schouten wrote:
I'm a little confused, when I force OOM my firefox build on 64-bit
windows it -definitely- goes down before it reaches more than 3GB of
working set. Am I missing something here?
I think so. I did not mention working set at all. I am merely
calculating whether users are running win64 or win32, based on whether
they have 4G of total VM size (win64) or 2G/3G (win32).
I should highlight something here, caching the last N textures is only
occurring in drivers which do -not- map into your address space as far as I
have see in my testing. Intel stock drivers seem to map into your address
space, but do -not- seem to do any caching. The most likely cause of the OOM
here is simply that currently, we keep both the texture, and a RAM copy around
of any image in our image cache that has been drawn. This means for users using
Direct2D with these drivers an image will use twice as much address space as
for users using software rendering. We should probably alter imagelib to
discard the RAM copy when having hardware acceleration, and in that case actual
address space usage should be the same for users with, and without hardware
acceleration.
Given that the recent Firefox 25 regression occurs for users whether
acceleration is enabled or disabled, I don't think that acceleration is
the thing we should be focusing on short-term. But yes, we should
continue to measure and correct for VM usage as well as total memory
usage in the graphics space.
I also suspect that we're not dealing with normal memory usage: it seems
clear that we're leaking someting, because the users who are helping
figure this out can clearly see issues by loading just a few youtube
pages in HTML5 video mode and then refreshing them a few times.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
