[olpc-software] XRes Improvements

[Daniel P. Berrange]

On Tue, Mar 14, 2006 at 10:12:47PM -0800, L. David Baron wrote:
> On Tuesday 2006-03-14 21:53 +0000, Daniel P. Berrange wrote:
> > http://people.redhat.com/berrange/olpc/performance/
> 
> ...in which you wrote:
> 
> # Running these tests revealed some interesting & unexpected results.
> # The first test starting releasing pixmaps on the X server when total
> # memory usage hit about 74 MB, with 12 pages loaded into history. The
> # remaining tests *never* freed any pixmaps even after 50 pages / 220 MB
> # of pixmaps are loaded. The stack traces associted with the XFreePixmap
> # calls show some form of reference counting garbage collection is
> # taking place to release pixmaps. The graphs would later tests suggest
> # that this reference counting is broken when multiple tabs are open. On
> # the plus side, the client side memory usage appears to be sane, with
> # the only significant increase in usage being demonstrated when opening
> # a new tab for every single web page loaded.
> 
> I tried some non-automated testing in trunk Firefox, and found (in gdb)
> that XFreePixmap was being called when I expected it to be, even when
> loading various images alternately between two tabs.  Loading new images
> evicted old ones from the memory cache, calling XFreePixmap.  (I had to
> weed out *tons* of other XFreePixmap calls related to temporary drawing
> surfaces, and some related to Xft, though.)

You might like to try out these tools

http://people.redhat.com/berrange/olpc/performance/capture-pixmap-0.8.1.tar.gz

Which let you capture stack traces & visually identify interesting 
pixmaps, ignoring the transient ones used for drawing.

> I could try to see if I can replicate these results if I knew what
> versions of both Firefox and Epiphany you were using.  Some versions are
> nontrivial for me to build and install, especially since current
> epiphany doesn't build on FC4 (it's too old!).

I'm using the packages from Fedora Core 5 rawhide, which are

  epiphany-1.9.8-1
  mozilla-1.7.12
  firefox-1.5.0.1

> The reference counting shouldn't be too error-prone, although there are
> actually multiple reference counts to care about, since the refcounted
> nsImageGTK objects in Mozilla own a reference to refcounted GdkPixmap
> objects which in turn own the pixmap.  I'd think Mozilla would be likely
> to leak those nsImageGTK objects mainly in the case where it leaked a
> substantial chunk of the data structures for the entire document, but I
> could be wrong.

Yes, I've not been able to get any visibility onto whether the client side
document data structures are being leaked or not. The trace for the code
allocating the pixmaps is:

  1 trace:0x2006
  2 XCreatePixmap:0x2323
  3 IA__gdk_pixmap_new:0x4fb08
  4 nsImageGTK::CreateOffscreenPixmap(int, int):0x28023
  5 nsImageGTK::Optimize(nsIDeviceContext*):0x28126
  6 gfxImageFrame::SetMutable(int):0x51e6c
  7 png_push_read_chunk:0x1f098
  8 png_process_data:0x1fb1c
  9 ReadDataOut:0xdc20
 10 nsPipeInputStream::ReadSegments(unsigned int (*)(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int
*):0x7d257
 11 nsPNGDecoder::WriteFrom(nsIInputStream*, unsigned int, unsigned int*):0xdb4d
 12 imgRequest::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int):0xc9d3
 13 nsInputStreamPump::OnStateTransfer():0x2edbd
 14 nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*):0x2eec4
 15 nsCOMPtr<nsIInputStreamCallback>::operator=(nsIInputStreamCallback*):0x7dfd5
 16 PL_HandleEvent:0x95059
 17 PL_ProcessPendingEvents:0x952fa
 18 nsEventQueueImpl::ProcessPendingEvents():0x9709d
 19 event_processor_callback:0x1a772
 20 g_main_dispatch:0x26f7a
 21 g_main_context_iterate:0x2a105
 22 IA__g_main_loop_run:0x2a42d
 23 IA__gtk_main:0x11ece3
 24 main:0x3a182
 25 __libc_start_main:0x1d084
 26 __gxx_personality_v0:0x39939


And the trace for the code which frees it during normal operation is

  1 trace:0x2006
  2 XFreePixmap:0x2111
  3 gdk_pixmap_impl_x11_finalize:0x4fd04
  4 IA__g_object_unref:0xd0f8
  5 gdk_pixmap_finalize:0x27a4d
  6 IA__g_object_unref:0xd0f8
  7 ~nsImageGTK:0x27475
  8 nsImageGTK::Release():0x26de1
  9 ~gfxImageFrame:0x52785
 10 gfxImageFrame::Release():0x52421
 11 ~nsCOMPtr:0x7cad
 12 imgContainer::Release():0x7b81
 13 ~nsCOMPtr:0xbb28
 14 imgRequest::Release():0xae46
 15 EventHandler:0x7b412
 16 PL_HandleEvent:0x95059
 17 PL_ProcessPendingEvents:0x952fa
 18 nsEventQueueImpl::ProcessPendingEvents():0x9709d
 19 event_processor_callback:0x1a772
 20 g_main_dispatch:0x26f7a
 21 g_main_context_iterate:0x2a105
 22 IA__g_main_loop_run:0x2a42d
 23 IA__gtk_main:0x11ece3
 24 main:0x3a182
 25 __libc_start_main:0x1d084
 26 __gxx_personality_v0:0x39939


Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|