Status

()

Toolkit
about:memory
--
enhancement
VERIFIED FIXED
8 years ago
5 years ago

People

(Reporter: RNicoletto, Assigned: vlad)

Tracking

(Blocks: 1 bug, {dev-doc-complete, user-doc-needed})

Trunk
x86
All
dev-doc-complete, user-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

(Whiteboard: [parity Chrome])

Attachments

(5 attachments)

(Reporter)

Description

8 years ago
Created attachment 399464 [details]
Google Chrome 3.x "about:memory" page

One of the greatest features of Google Chrome is the "about:memory" page and I would like to see something similar in Mozilla Firefox.

Refer to bug 515352 description for more details about this enhancement request.

Just for reference: Memory Usage Backgrounder - Chromium Memory Usage (http://dev.chromium.org/memory-usage-backgrounder)

Updated

8 years ago
Whiteboard: [parity Chrome]
Version: unspecified → Trunk
related Bugs:
Bug 392351 and dependencies
Bug 400120
Bug 453420 comment 3
(Reporter)

Updated

8 years ago
Depends on: 400120, 167035
No longer depends on: 515352
(Reporter)

Comment 2

8 years ago
Added another bug dependecy:
Bug 167035
Duplicate of this bug: 515352
Created attachment 400872 [details] [diff] [review]
export jemalloc.h and jemalloc_stats symbol

This only changes the VC9 jemalloc patch; we need something else that will change the VC8 one.  This is a requirement for the following patch.
Assignee: nobody → vladimir
Created attachment 400875 [details] [diff] [review]
about:memory

Simple about:memory implementation.  Displays a page that basically dumps all the reporters when refreshed.  Should be good enough to build on top of.

We'll have to figure out localization; I'm thinking that we support a properties file where we look up the reporter path ("malloc/committed"), and if a string for that is present, we use that -- otherwise we use the path itself.
Attachment #400875 - Flags: review?
Attachment #400875 - Flags: review? → review?(mconnor)
Created attachment 400878 [details]
screenshot

Screenshot of what this looks like.  Note that jemalloc is giving some bogus numbers currently.
Comment on attachment 400872 [details] [diff] [review]
export jemalloc.h and jemalloc_stats symbol

Ted, is exporting jemalloc.h in this way ok?  Seems to work fine.

Er, I have no idea why this patch removed the header from the _sample_.rc diff.  Ignore that hunk.
Attachment #400872 - Flags: review?(ted.mielczarek)

Updated

8 years ago
Attachment #400875 - Flags: review?(mconnor) → review+
Comment on attachment 400875 [details] [diff] [review]
about:memory


>diff --git a/toolkit/components/aboutmemory/content/aboutMemory.js b/toolkit/components/aboutmemory/content/aboutMemory.js

code looks fine, there's random tab chars in places (noticed since diff indentation was wacky)

>+function doLoad()
>+{
>+    netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");

as noted, this isn't needed anymore.

this looks good overall, woo!

r=mconor
Comment on attachment 400872 [details] [diff] [review]
export jemalloc.h and jemalloc_stats symbol

Seems sane. Remember to put the crt patch license header back in before landing. Also, I'll get you a VC8 version of this soon, I promise.
Attachment #400872 - Flags: review?(ted.mielczarek) → review+
Any chance of getting this as an XPI for 3.6? I'm almost willing to land this in all locales with en-US strings, really.
Created attachment 403280 [details] [diff] [review]
VC8 CRT patch patch

This is an equivalent patch for the VC8 CRT patch. There's some extra changes (in there that I don't fully understand (but look harmless, and build fine), so if you want to be extra paranoid, I think you can actually just hand-edit crtvc8sp1.diff, and add that jemalloc_stats line directly below malloc_usable_size.
Might be stray whitespace junk from previous fiddling, I would recommend just hand-editing the VC8 patch. You can probably tryserver it to sanity check yourself.
So this all works great on Windows, but on Linux the libxul link fails -- it can't find jemalloc_stats.  Indeed, we don't actually link jemalloc into libxul, but instead link it directly to the browser app.  Is there any reason we do this?  Can we just make it part of libxul?
Yes, the reason is that if you make jemalloc part of libxul you totally screw over all the embedders who will end up with mixed allocators (you end up replacing malloc/free midway through running their app).
Checked in, disabled on Linux due to linkage issues.  On Mac, it reports the OSX allocator's zone 0 stats.

http://hg.mozilla.org/mozilla-central/rev/ed8c714d33ad
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Depends on: 520364

Updated

8 years ago
Blocks: 167035, 400120
No longer depends on: 167035, 400120
vlad, can we get this for 192?

Comment 17

8 years ago
What are the values measure in? Bytes, MB, K, KB, GB?

Comment 18

8 years ago
Some of these figures are really bogus. I watched the 'memory mapped' counter going to 0, and then it became negative :

Memory mapped:	4,284,481,536
Memory in use:	100,894,418
	
malloc/allocated 100,903,002
malloc/mapped 4,284,481,536
malloc/committed 39,411,712
malloc/dirty 2,895,872
Depends on: 520422

Updated

8 years ago
Blocks: 520467

Updated

8 years ago
No longer blocks: 520467
Depends on: 520467
The bogus values are known -- there's a jemalloc stats bug, but it'll be fixed separately... bug 515556.
Depends on: 515556
Attachment #400875 - Flags: approval1.9.2+

Comment 20

8 years ago
There's a typo in the tooltip text, commited instead of committed.
Committed is the EN-US spelling I believe. For EN-UK, it is probably commited.
(In reply to comment #20)
> There's a typo in the tooltip text, commited instead of committed.

Fixed -- http://hg.mozilla.org/mozilla-central/rev/8afae2d77f31
Vlad: any chance you can help describe in human terms what the values are so that the SUMO and MDC guys can write this up?
Keywords: dev-doc-needed, user-doc-needed
Whiteboard: [parity Chrome] → [parity Chrome][doc-waiting-1.9.3]
Pushed to 192:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/47c8830c87ec
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/27230e3ceea2
status1.9.2: --- → beta1-fixed
Is this really resolved/fixed if it isn't implemented on Linux?

Comment 26

8 years ago
An enhancement request bug 521522 
-  about:memory should automatically refresh every 5 sec (configurable)
(In reply to comment #25)
> Is this really resolved/fixed if it isn't implemented on Linux?

A follow up should be levied against implementing it on all other platforms: Linux, Maemo, WinCE
I think this would be an ideal addition to the support article <https://support.mozilla.com/en-US/kb/High+memory+usage>, but when I look at about:memory, I have no idea how to use this feature. Can someone tell me?

Updated

8 years ago
Depends on: 534848
Added a mention of this here:

https://developer.mozilla.org/en/Debugging_memory_leaks
Keywords: dev-doc-needed → dev-doc-complete
Whiteboard: [parity Chrome][doc-waiting-1.9.3] → [parity Chrome]

Updated

7 years ago
Status: RESOLVED → VERIFIED
Component: IPC → about:memory
Product: Core → Toolkit
QA Contact: ipc → about.memory
You need to log in before you can comment on or make changes to this bug.