10850 - Massive footprint of viewer/apprunner

Status: VERIFIED DUPLICATE of bug 11062

(Core :: XPCOM, defect, P3)

Description

[tor]

viewer and apprunner currently have a massive startup footprint on
unix platforms, 156Mb and 167Mb respectively.  It turns out that most
of this is a 128Mb mmap of /dev/zero by the nsPageMgr.
xpcom/ds/nsPageMgr.cpp line 323 maps a region of size
(size<<NS_PAGEMGR_PAGE_BITS), which turns out to be (32767<<12).
What is this chunk of memory used for, and does it need to be this
big?

  [1] _mmap(0x0, 0x7fff000, 0x3, 0x2, 0x9, 0x0), at 0xfe29408c
=>[2] nsPageMgr::InitPages(this = 0x161438, minPages = 32U, maxPages = 32767U),
line 323 in "nsPageMgr.cpp"
  [3] nsPageMgr::Init(this = 0x161438, minPages = 32U, maxPages = 32767U), line
422 in "nsPageMgr.cpp"
  [4] nsPageMgr::Create(aOuter = (nil), aIID = STRUCT, aResult = 0xffbee200),
line 467 in "nsPageMgr.cpp"
  [5] nsGenericFactory::CreateInstance(this = 0x89fe8, aOuter = (nil), aIID =
STRUCT, aResult = 0xffbee200), line 53 in "nsGenericFactory.cpp"
  [6] nsComponentManagerImpl::CreateInstance(this = 0x88700, aClass = STRUCT,
aDelegate = (nil), aIID = STRUCT, aResult = 0xffbee200), line 1277 in
"nsComponentManager.cpp"
  [7] nsComponentManager::CreateInstance(aClass = STRUCT, aDelegate = (nil),
aIID = STRUCT, aResult = 0xffbee200), line 67 in "nsRepository.cpp"
  [8] nsServiceManagerImpl::GetService(this = 0x848e8, aClass = STRUCT, aIID =
STRUCT, result = 0xffbee38c, shutdownListener = (nil)), line 243 in
"nsServiceManager.cpp"
  [9] nsServiceManager::GetService(aClass = STRUCT, aIID = STRUCT, result =
0xffbee38c, shutdownListener = (nil)), line 445 in "nsServiceManager.cpp"
  [10] nsService::nsService(this = 0xffbee37c, aClass = STRUCT, aIID = STRUCT,
rv = 0xffbee390), line 290 in "nsIServiceManager.h"
  [11] NS_NewPageBuffer(result = 0xffbee3fc, growBySize = 4096U, maxSize =
1048576U, observer = 0x161338), line 707 in "nsBuffer.cpp"
  [12] NS_NewPipe(inStrResult = 0x161370, outStrResult = 0x161374, growBySize =
4096U, maxSize = 1048576U, blocking = 1, observer = 0x161338), line 585 in
"nsPipe.cpp"
  [13] nsFileChannel::AsyncRead(this = 0x161330, startPosition = 0, readCount =
-1, ctxt = (nil), listener = 0x160bf8), line 534 in "nsFileChannel.cpp"
  [14] ImageNetContextImpl::GetURL(this = 0x15a658, aURL = 0x15de80, aLoadMethod
= NET_NORMAL_RELOAD, aReader = 0x15df70), line 596 in
"nsImageNetContextAsync.cpp"
  [15] IL_GetImage(image_url = 0xffbee828 "resource:/res/throbber/anims00.gif",
img_cx = 0x1608c8, obs_list = 0x15de38, background_color = 0xffbee71c, req_width
= 30U, req_height = 30U, flags = 0, opaque_cx = 0x15a590), line 2045 in "if.cpp"
  [16] ImageRequestImpl::Init(this = 0x15d510, aGroupContext = 0x1608c8, aUrl =
0xffbee828 "resource:/res/throbber/anims00.gif", aObserver = 0x15e834,
aBackgroundColor = 0xffbee814, aWidth = 30U, aHeight = 30U, aFlags = 0,
aNetContext = 0x15a590), line 240 in "nsImageRequest.cpp"
  [17] ImageGroupImpl::GetImage(this = 0x160898, aUrl = 0xffbee828
"resource:/res/throbber/anims00.gif", aObserver = 0x15e834, aBackgroundColor =
0xffbee814, aWidth = 30U, aHeight = 30U, aFlags = 0), line 271 in
"nsImageGroup.cpp"
  [18] nsThrobber::LoadThrobberImages(this = 0x15e830, aFileNameMask = CLASS,
aNumImages = 29), line 465 in "nsThrobber.cpp"
  [19] nsThrobber::Init(this = 0x15e830, aParent = 0x131c48, aBounds = STRUCT,
aFileNameMask = CLASS, aNumImages = 29), line 343 in "nsThrobber.cpp"
  [20] nsBrowserWindow::CreateToolBar(this = 0x131b10, aWidth = 620), line 1384
in "nsBrowserWindow.cpp"
  [21] nsBrowserWindow::Init(this = 0x131b10, aAppShell = 0x8b220, aPrefs =
0xa0b30, aBounds = STRUCT, aChromeMask = 4294967295U, aAllowPlugins = 1), line
1172 in "nsBrowserWindow.cpp"
  [22] nsViewerApp::OpenWindow(this = 0x881c0), line 599 in "nsViewerApp.cpp"
  [23] nsNativeViewerApp::Run(this = 0x881c0), line 41 in "nsGTKMain.cpp"
  [24] main(argc = 2, argv = 0xffbef64c), line 89 in "nsGTKMain.cpp"

Comment 1

[Warren Harris]

Mine.

Comment 2

[Warren Harris]

This buffer size was bumped up because we were experiencing another bug when we
ran out of buffer space. I'm still working on what the best size and heuristics
for grabbing this memory are.

Comment 3

[Warren Harris]

I reduced this, but bug 11062 remains to address additional problems.

*** This bug has been marked as a duplicate of 11062 ***

Comment 4

[Jay Patel [:jay]]

verified dup