Bugzilla

Updated

•

13 years ago

Assignee: nobody → general

Component: General → JavaScript Engine

Product: Firefox → Core

QA Contact: general → general

Comment 2

•

13 years ago

This also happens on Nightly (55mb-ish compartment for Facebook when opening two of those links), so nothing in the intervening time has fixed it.

26mb for the first link
55mb when I also opened the second link
78mb when I also opened the third link
270mb when I also opened the 5th link in a new tab, and Firefox also became fairly laggy

After closing the first 3 links, the JS compartment for https://www.facebook.com/extern/login_status.php remained at 200mb, so http://www.globes.co.il/news/article.aspx?did=1000681089 apparently results in a very large FB compartment by itself.

Updated

•

13 years ago

Summary: huge memory use,mostly Facebook JS,on non-Facebook site (80MB per tab) → Facebook JS compartment on non-Facebook site uses 25-200MB per tab

Whiteboard: [Memshrink] → [MemShrink]

Comment 3

•

13 years ago

http://www.globes.co.il/news/article.aspx?did=1000681089 takes about 280MB in Chrome (for the entire page, not just JS, which is what I was measuring for Firefox).

:aceman

Comment 4

•

13 years ago

That seems quite comparable (Chrome 280MB total vs. Firefox 200MB JS + X MB of some layout etc).

Comment 5

•

13 years ago

On a random Washington Post story, that FB compartment only takes about 4MB.  On the TechCrunch front page, after scrolling down the page slowly so all the little widgets load up, that compartment takes about 22MB, and on a single TechCrunch story that FB compartment takes only a few megs.

Reporter

Comment 6

•

13 years ago

I guess that what distinguishes http://www.globes.co.il/news/article.aspx?did=1000681089 higher memory consumption from the rest of the links, is that it has a large number of comments, 1007, on the article, although those 1007 comments are not displayed on the article page, just the last ~20 comments.
When clicking with the mouse to open a comment, you can see that basically each comment has a Facebook "recommend" button, and a Google "+1" button. (strangely some of the comments are missing the Facebook "recommend" button, which may be a bug ...)

There is a button/link for loading more comments at the bottom. When pressing it the comments load instantly so it seems all 1007 comments are preloaded, but just the ~20 are displayed at the start.

If the page takes ~200MB facebook JS memory for all ~1000 comments, that means ~200KB per comment, which is still a lot. 

As I said in my opening comment, even if this is a Facebook problem, I think it should be addressed by mozilla, with Facebook contact people, since it makes Firefox be perceived by users as very memory hungry on a lot of sites since Facebook "recommend" button is used on many sites.

Andreas Gal :gal

Comment 7

•

13 years ago

Andrew, we should contact FB. I will email you a contact.

Reporter

Comment 8

•

13 years ago

Please note that this bug is not only about the Facebook JS memory problem, so Mozilla developers should check it further, and not wait for Facebook.

As I wrote when reporting the bug on the first comment:"Facebook is not the only problem on this site. Even without considering facebook, Firefox used for the globes site itself 119MB for javascript (10MB per tab), and uses a lot of memory,228MB, categorized in heap unclassified (~20MB per tab)"

That is an additional ~30MB memory on average per tab !, memory which is apparently not related to Facebook .

Andrew Mccreight changed the summary to make it only a Facebook JS memory bug, but the original intention was about all memory problems on this site.

(Summary: huge memory use,mostly Facebook JS,on non-Facebook site (80MB per tab) ➔ Facebook JS compartment on non-Facebook site uses 25-200MB per tab )

you can take as a testcase only this link:
http://www.globes.co.il/news/article.aspx?did=1000681089

When you open Firefox with "about:blank", "about:memory" shows something like:
30 MB (100.0%) -- explicit
├──15 MB  -- js
├───11 MB -- heap-unclassified

When you open the link above, "about:memory" shows this (unnecessary details omitted):
445.10 MB (100.0%) -- explicit
├──337.25 MB (75.77%) -- js
│  ├──254.14 MB (57.10%) -- compartment(https://www.facebook.com/extern/login_status.php...
│  ├───35.33 MB (07.94%) -- compartment(http://www.globes.co.il/news/article.aspx?did=1000681089)
│  │   ├──17.93 MB (04.03%) -- gc-heap
│  │   │  ├───7.44 MB (01.67%) -- objects
│  │   │  ├───6.41 MB (01.44%) -- shapes
│  │   │  ├───3.03 MB (00.68%) -- arena-unused
│  │   │  └───1.06 MB (00.24%) -- (5 omitted)
│  │   ├──12.07 MB (02.71%) -- string-chars
│  │   └───5.33 MB (01.20%) -- (9 omitted)
│  ├────3.91 MB (00.88%) -- compartment(http://www.facebook.com/plugins/activity.php...
├───86.94 MB (19.53%) -- heap-unclassified

Which means that apart from Facebook taking 260MB memory on this page, there is a globes JS compartment taking 35MB for just this one page, and an additional 70MB in "heap-unclassified", compared to the results of "about:blank".
i.e. a total of 100MB for this one page (!), that is apparently unrelated to Facebook.

Even if (for the sake of discussion) you claim that Globes JS is allocating that much heap memory and there is nothing you can do, then what can possibly be in "heap-unclassified" that requires 70MB for one page ?

Comment 9

•

13 years ago

35MB of JS for a tab isn't really that much for a complex JS website.  Gmail is currently using about that much for me.

Similarly, 20% heap-unclassified is actually on the low side.  I currently have 22% heap-unclassified in my browser.  It is unfortunate that it is routinely so high.  We do have some ongoing efforts to improve this, in the dependent bugs in Bug 563700.

While it would obviously be great to improve both numbers, as far as I can see it is only the gigantic Facebook compartment that is unusual.  As you pointed out in Comment 6, the really big page has a huge number of comments, so perhaps the Facebook commenting widget is downloading all the comments.

Boris Zbarsky [:bzbarsky]

Updated

•

13 years ago

OS: Windows 7 → All

Hardware: x86 → All

:aceman

Comment 10

•

13 years ago

This is about:memory with the http://www.globes.co.il/news/article.aspx?did=1000681089 loaded and facebook blocked on the firewall.
There is 32% of heap unclassified.

Explicit Allocations
178.93 MB (100.0%) -- explicit
├──101.43 MB (56.69%) -- js
│  ├───49.21 MB (27.50%) -- (216 omitted)
│  ├───27.12 MB (15.15%) -- compartment(http://www.globes.co.il/news/article.aspx?did=1000681089)
│  │   ├──12.62 MB (07.05%) -- string-chars
│  │   ├──10.75 MB (06.01%) -- gc-heap
│  │   │  ├───4.38 MB (02.45%) -- arena-unused
│  │   │  ├───3.32 MB (01.85%) -- objects
│  │   │  ├───2.29 MB (01.28%) -- shapes
│  │   │  └───0.76 MB (00.43%) -- (5 omitted)
│  │   ├───2.68 MB (01.50%) -- (8 omitted)
│  │   └───1.06 MB (00.59%) -- mjit-code
│  │       └──1.06 MB (00.59%) -- (3 omitted)
│  ├───10.29 MB (05.75%) -- compartment([System Principal], 0xffffffffb3155000)
│  │   ├───5.82 MB (03.26%) -- gc-heap
│  │   │   ├──2.30 MB (01.29%) -- objects
│  │   │   ├──1.44 MB (00.81%) -- shapes
│  │   │   ├──1.28 MB (00.72%) -- arena-unused
│  │   │   └──0.80 MB (00.45%) -- (6 omitted)
│  │   ├───2.35 MB (01.31%) -- (10 omitted)
│  │   ├───1.12 MB (00.62%) -- script-data
│  │   └───1.00 MB (00.56%) -- mjit-code
│  │       └──1.00 MB (00.56%) -- (3 omitted)
│  ├────8.00 MB (04.47%) -- stack
│  ├────5.05 MB (02.82%) -- gc-heap-chunk-dirty-unused
│  └────1.77 MB (00.99%) -- compartment(atoms)
│       ├──1.10 MB (00.61%) -- string-chars
│       └──0.67 MB (00.38%) -- (1 omitted)
├───57.22 MB (31.98%) -- heap-unclassified
├────7.62 MB (04.26%) -- layout
│    ├──4.02 MB (02.25%) -- shell(about:memory?verbose)
│    │  ├──3.98 MB (02.22%) -- arenas
│    │  └──0.04 MB (00.02%) -- (1 omitted)
│    ├──2.06 MB (01.15%) -- (19 omitted)
│    └──1.54 MB (00.86%) -- shell(http://www.globes.co.il/news/article.aspx?did=1000681089)
│       ├──1.29 MB (00.72%) -- arenas [3]
│       └──0.25 MB (00.14%) -- (1 omitted)
├────4.59 MB (02.57%) -- dom
├────3.89 MB (02.17%) -- storage
│    └──3.89 MB (02.17%) -- sqlite
│       ├──2.17 MB (01.21%) -- (10 omitted)
│       └──1.72 MB (00.96%) -- places.sqlite
│          ├──1.48 MB (00.83%) -- cache-used [4]
│          └──0.24 MB (00.13%) -- (2 omitted)
├────2.21 MB (01.23%) -- spell-check
├────1.10 MB (00.61%) -- images
│    ├──1.06 MB (00.59%) -- content
│    │  ├──1.06 MB (00.59%) -- used
│    │  │  └──1.06 MB (00.59%) -- (3 omitted)
│    │  └──0.00 MB (00.00%) -- (1 omitted)
│    └──0.04 MB (00.02%) -- (1 omitted)
└────0.87 MB (00.49%) -- (3 omitted)

Those 216 ommited reporters are actually frames with Network error (as facebook is not accessible). Their total size of 49MB is quite disgusting.

│  ├──────235,552 B (00.14%) -- compartment(about:neterror?e=connectionFailure&u=https%3A//www.facebook.com/plugins/like.php%3Faction%3Drecommend%26api_key%3D159652850757022%26channel_url%3Dhttps%253A%252F%252Fs-static.ak.fbcdn.net%252Fconnect%252Fxd_proxy.php%253Fversion%253D3%2523cb%253Df3947e871a1dc64%2526origin%253Dhttp%25253A%25252F%25252Fwww.globes.co.il%25252Ff3b6c2563791242%2526relation%253Dparent.parent%2526transport%253Dpostmessage%26extended_social_context%3Dfalse%26font%3Darial%26href%3Dhttp%25253A%252F%252Fwww.globes.co.il%252Fnews%252Farticle.aspx%25253Fresid%25253D124099%26layout%3Dbutton_count%26locale%3Den_US%26node_type%3Dlink%26sdk%3Djoey%26send%3Dfalse%26show_faces%3Dfalse%26width%3D130&c=UTF-8&d=Firefox%20can%27t%20establish%20a%20connection%20to%20the%20server%20at%20www.facebook.com.)
│  │      ├──147,456 B (00.09%) -- gc-heap
│  │      │  ├───51,424 B (00.03%) -- arena-unused
│  │      │  ├───48,240 B (00.03%) -- objects
│  │      │  ├───44,080 B (00.03%) -- shapes
│  │      │  ├────1,360 B (00.00%) -- scripts
│  │      │  ├────1,312 B (00.00%) -- type-objects
│  │      │  ├──────576 B (00.00%) -- arena-headers
│  │      │  ├──────320 B (00.00%) -- arena-padding
│  │      │  └──────144 B (00.00%) -- strings
│  │      ├───65,536 B (00.04%) -- mjit-code
│  │      │   ├──64,392 B (00.04%) -- unused
│  │      │   ├───1,064 B (00.00%) -- regexp
│  │      │   └──────80 B (00.00%) -- method
│  │      ├───10,560 B (00.01%) -- object-slots
│  │      ├────5,664 B (00.00%) -- property-tables
│  │      ├────2,864 B (00.00%) -- script-data
│  │      ├────1,456 B (00.00%) -- type-inference
│  │      │    └──1,456 B (00.00%) -- object-main
│  │      ├────1,120 B (00.00%) -- shape-kids
│  │      ├──────768 B (00.00%) -- object-empty-shapes
│  │      └──────128 B (00.00%) -- string-chars

Comment 11

•

13 years ago

The most likely explanation here is that each of those Like buttons is in fact active at once.  So there is one iframe per like button, with some facebook JS in that iframe.  That means lots of copies of that script, etc.

If we shared the JSScript across all those, we could probably win big here...

Reporter

Comment 12

•

13 years ago

(In reply to Andrew McCreight [:mccr8] from comment #9)
> 35MB of JS for a tab isn't really that much for a complex JS website.  Gmail
> is currently using about that much for me.

Note also that the Globes Javascript compartment is using ~12.5MB for string-chars, whereas the Facebook compartment doesn't use that large amount (only ~300KB). Note also that this link has a larger number of string-chars reported than for example the first globes link (which has less than 1MB string-chars), therefore I suspect that it relates to the number of comments (1007) on this page.

What is it used for? 
If the comments are stored in the JS memory then if the page has 1000 comments, each with 1K characters on average (and this is exaggerated, the average is much lower, since most comments are a short text of a few lines), then it needs on the order of about 1M of string-chars to store, much less than the 12MB it uses.
Is it possible that there is inadequate use of JS memory by Firefox in this case?

Can someone explain or find out why does it use so much string-chars memory?

Johnny Stenback (:jst)

Updated

•

13 years ago

Whiteboard: [MemShrink] → [MemShrink:P2]

Comment 13

•

13 years ago

I can probably modify some JS heap dumping tools to get the strings in the compartment.

Comment 14

•

13 years ago

I checked this again, and the FB compartment was only around 7 MB for the first few links.  The really huge one (1000681089) is still really huge, however.

Boris Zbarsky [:bzbarsky]

Reporter

Comment 15

•

13 years ago

(In reply to Boris Zbarsky (:bz) from comment #11)
> The most likely explanation here is that each of those Like buttons is in
> fact active at once.  So there is one iframe per like button, with some
> facebook JS in that iframe.  That means lots of copies of that script, etc.
> 
> If we shared the JSScript across all those, we could probably win big here...

Can someone estimate, for the reference, what needs to be done, and how much complicated is this (sharing JS between iframes, as I understand)?

Comment 16

•

13 years ago

Luke has some work in progress to allow doing it to start with (nixing compile-n-go and so forth).  Then we need to actually store the JSScript somewhere we can retrieve it from.  See bug 679942 and its dependencies.

Comment 17

•

13 years ago

opened facebook, this is a 8-12MB compartment

│  ├───9.49 MB (13.27%) -- compartment(http://www.facebook.com/)
│  │   ├──5.66 MB (07.92%) -- gc-heap
│  │   │  ├──2.38 MB (03.33%) -- arena
│  │   │  │  ├──2.33 MB (03.26%) -- unused
│  │   │  │  └──0.05 MB (00.07%) -- (2 omitted)
│  │   │  ├──1.58 MB (02.22%) -- objects
│  │   │  │  ├──0.85 MB (01.18%) -- non-function
│  │   │  │  └──0.74 MB (01.03%) -- function
│  │   │  ├──0.96 MB (01.35%) -- shapes
│  │   │  │  ├──0.69 MB (00.97%) -- tree
│  │   │  │  └──0.27 MB (00.38%) -- (1 omitted)
│  │   │  ├──0.53 MB (00.74%) -- scripts
│  │   │  └──0.20 MB (00.29%) -- (2 omitted)
│  │   ├──1.06 MB (01.49%) -- mjit-code
│  │   │  ├──0.89 MB (01.24%) -- method
│  │   │  └──0.18 MB (00.25%) -- (2 omitted)
│  │   ├──1.01 MB (01.42%) -- (3 omitted)
│  │   ├──0.82 MB (01.15%) -- script-data
│  │   ├──0.54 MB (00.75%) -- type-inference
│  │   │  ├──0.39 MB (00.54%) -- script-main
│  │   │  └──0.15 MB (00.21%) -- (2 omitted)
│  │   └──0.39 MB (00.54%) -- shapes-extra
│  │      └──0.39 MB (00.54%) -- (4 omitted)

opened 18 tabs containing the mangafox homepage (has a facebook share button)

│  ├───77.22 MB (20.33%) -- compartment(http://www.facebook.com/)
│  │   ├──39.33 MB (10.36%) -- gc-heap
│  │   │  ├──16.31 MB (04.30%) -- objects
│  │   │  │  ├──11.12 MB (02.93%) -- function
│  │   │  │  └───5.19 MB (01.37%) -- non-function
│  │   │  ├───9.98 MB (02.63%) -- shapes
│  │   │  │   ├──7.60 MB (02.00%) -- tree
│  │   │  │   └──2.39 MB (00.63%) -- dict
│  │   │  ├───8.60 MB (02.26%) -- scripts
│  │   │  ├───2.13 MB (00.56%) -- type-objects
│  │   │  ├───2.13 MB (00.56%) -- arena
│  │   │  │   └──2.13 MB (00.56%) -- (3 omitted)
│  │   │  └───0.18 MB (00.05%) -- (1 omitted)
│  │   ├──14.27 MB (03.76%) -- script-data
│  │   ├──10.25 MB (02.70%) -- mjit-code
│  │   │  ├───8.74 MB (02.30%) -- method
│  │   │  └───1.51 MB (00.40%) -- (2 omitted)
│  │   ├───4.98 MB (01.31%) -- type-inference
│  │   │   ├──3.17 MB (00.83%) -- script-main
│  │   │   └──1.82 MB (00.48%) -- (2 omitted)
│  │   ├───3.72 MB (00.98%) -- shapes-extra
│  │   │   ├──2.56 MB (00.68%) -- tree-tables
│  │   │   └──1.15 MB (00.30%) -- (3 omitted)
│  │   ├───3.19 MB (00.84%) -- object-slots
│  │   └───1.49 MB (00.39%) -- (2 omitted)

closed the facebook tab, leaving the 18 instances of the mangafox home page open

│  ├───69.77 MB (18.89%) -- compartment(http://www.facebook.com/)
│  │   ├──38.05 MB (10.30%) -- gc-heap
│  │   │  ├──14.74 MB (03.99%) -- objects
│  │   │  │  ├──10.38 MB (02.81%) -- function
│  │   │  │  └───4.36 MB (01.18%) -- non-function
│  │   │  ├───9.15 MB (02.48%) -- shapes
│  │   │  │   ├──7.05 MB (01.91%) -- tree
│  │   │  │   └──2.10 MB (00.57%) -- dict
│  │   │  ├───8.07 MB (02.19%) -- scripts
│  │   │  ├───3.98 MB (01.08%) -- arena
│  │   │  │   ├──3.75 MB (01.01%) -- unused
│  │   │  │   └──0.24 MB (00.06%) -- (2 omitted)
│  │   │  ├───2.01 MB (00.54%) -- type-objects
│  │   │  └───0.09 MB (00.03%) -- (1 omitted)
│  │   ├──13.44 MB (03.64%) -- script-data
│  │   ├───9.56 MB (02.59%) -- mjit-code
│  │   │   ├──8.09 MB (02.19%) -- method
│  │   │   └──1.47 MB (00.40%) -- (2 omitted)
│  │   ├───3.36 MB (00.91%) -- shapes-extra
│  │   │   ├──2.33 MB (00.63%) -- tree-tables
│  │   │   └──1.03 MB (00.28%) -- (3 omitted)
│  │   ├───2.86 MB (00.77%) -- object-slots
│  │   └───2.49 MB (00.67%) -- (3 omitted)

then navigated each of those mangafox tabs to a different manga series from the home page (all 18 on a different page)

│  ├───25.49 MB (09.45%) -- compartment(http://www.facebook.com/)
│  │   ├──17.30 MB (06.42%) -- gc-heap
│  │   │  ├───7.45 MB (02.76%) -- arena
│  │   │  │   ├──7.34 MB (02.72%) -- unused
│  │   │  │   └──0.11 MB (00.04%) -- (2 omitted)
│  │   │  ├───4.37 MB (01.62%) -- objects
│  │   │  │   ├──3.18 MB (01.18%) -- function
│  │   │  │   └──1.19 MB (00.44%) -- (1 omitted)
│  │   │  ├───3.04 MB (01.13%) -- shapes
│  │   │  │   ├──2.45 MB (00.91%) -- tree
│  │   │  │   └──0.59 MB (00.22%) -- (1 omitted)
│  │   │  ├───1.83 MB (00.68%) -- scripts
│  │   │  └───0.61 MB (00.23%) -- (2 omitted)
│  │   ├───3.36 MB (01.25%) -- script-data
│  │   ├───1.64 MB (00.61%) -- shapes-extra
│  │   │   ├──1.35 MB (00.50%) -- tree-tables
│  │   │   └──0.28 MB (00.11%) -- (3 omitted)
│  │   ├───1.63 MB (00.60%) -- mjit-code
│  │   │   └──1.63 MB (00.60%) -- (3 omitted)
│  │   └───1.57 MB (00.58%) -- (4 omitted)

This is from a clean profile in 10b3

surely that facebook compartment on the mangafox home page is excessive.....

in all seriousness, there should be no reason at all for the like or share button to create such a huge compartment period. i could understand if it was a continuously running script but it just sits there useless 99% of the time, however after reading through this bug, it would actually appear the script IS constantly active!

Facebook is the enemy of the memshrink, lol.

Comment 18

•

12 years ago

Is someone looking into this bug ?
I seem to have discovered another issue, if any site contains a FB social plugin, a like button or anything like mentioned in the above comments, then it also causes Zombie compartments if you have a facebook.com tab opened side by side.
For example having both Facebook.com and 9gag.com tabs opeoned, I have : 
─2,333,184 B (01.08%) -- top=312 (inner=315)
│      │  │   ├────828,421 B (00.38%) -- inner-window(id=339, uri=https://www.facebook.com/plugins/comments.php?api_key=111569915535689&channel_url=https%3A%2F%2Fs-static.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df17cc1cd0b69958%26origin%3Dhttp%253A%252F%252F9gag.com%252Ffa54797aaf742a%26relation%3Dparent.parent%26transport%3Dpostmessage&href=http%3A%2F%2F9gag.com%2Fgag%2F2535083&locale=en_US&numposts=10&sdk=joey&width=700)
│      │  │   │    ├──515,965 B (00.24%) ── dom
│      │  │   │    └──312,456 B (00.14%) ── style-sheets
│      │  │   ├────676,677 B (00.31%) -- inner-window(id=315, uri=http://9gag.com/gag/2535083?ref=fb)
│      │  │   │    ├──545,632 B (00.25%) ── style-sheets
│      │  │   │    └──131,045 B (00.06%) ── dom
│      │  │   ├────218,806 B (00.10%) -- inner-window(id=352, uri=https://www.facebook.com/plugins/like.php?api_key=111569915535689&channel_url=https%3A%2F%2Fs-static.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df3d1c00768edae8%26origin%3Dhttp%253A%252F%252F9gag.com%252Ffa54797aaf742a%26relation%3Dparent.parent%26transport%3Dpostmessage&extended_social_context=false&href=http%3A%2F%2Ffacebook.com%2F9gag&layout=standard&locale=en_US&node_type=link&sdk=joey&send=false&show_faces=true&width=270)
│      │  │   │    ├──170,776 B (00.08%) ── style-sheets
│      │  │   │    └───48,030 B (00.02%) ── dom
│      │  │   ├────205,921 B (00.10%) -- inner-window(id=351, uri=https://www.facebook.com/plugins/like.php?api_key=111569915535689&channel_url=https%3A%2F%2Fs-static.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df27bba46e6ed47e%26origin%3Dhttp%253A%252F%252F9gag.com%252Ffa54797aaf742a%26relation%3Dparent.parent%26transport%3Dpostmessage&extended_social_context=false&href=http%3A%2F%2F9gag.com%2Fgag%2F2535083&layout=button_count&locale=en_US&node_type=link&sdk=joey&send=false&show_faces=false&width=90)
│      │  │   │    ├──171,080 B (00.08%) ── style-sheets
│      │  │   │    └───34,841 B (00.02%) ── dom
│      │  │   ├────111,366 B (00.05%) -- inner-window(id=336, uri=http://platform.twitter.com/widgets/follow_button.1326407570.html#_=1329133121577&_version=2&enableNewSizing=false&id=twitter-widget-2&lang=en&screen_name=9gag&size=m)
│      │  │   │    ├───84,814 B (00.04%) ── dom
│      │  │   │    └───26,552 B (00.01%) ── style-sheets
│      │  │  

as the breakdown of compartment created by FB on 9gag.
This is the 9gag.com breakdown
─4,592,296 B (02.12%) -- compartment(http://9gag.com/gag/2535083?ref=fb)
│  │    ├──2,666,496 B (01.23%) -- gc-heap
│  │    │  ├────932,744 B (00.43%) -- arena
│  │    │  │    ├──912,152 B (00.42%) ── unused
│  │    │  │    ├───10,416 B (00.00%) ── headers
│  │    │  │    └───10,176 B (00.00%) ── padding
│  │    │  ├────625,232 B (00.29%) -- objects
│  │    │  │    ├──325,056 B (00.15%) ── function
│  │    │  │    └──300,176 B (00.14%) ── non-function
│  │    │  ├────498,240 B (00.23%) ── scripts
│  │    │  ├────456,152 B (00.21%) -- shapes
│  │    │  │    ├──222,384 B (00.10%) ── tree
│  │    │  │    ├──182,184 B (00.08%) ── dict
│  │    │  │    └───51,584 B (00.02%) ── base
│  │    │  ├────144,416 B (00.07%) ── type-objects
│  │    │  └──────9,712 B (00.00%) ── strings
│  │    ├────835,776 B (00.39%) ── script-data
│  │    ├────376,512 B (00.17%) -- shapes-extra
│  │    │    ├──223,008 B (00.10%) ── tree-tables
│  │    │    ├───76,352 B (00.04%) ── dict-tables
│  │    │    ├───44,128 B (00.02%) ── tree-shape-kids
│  │    │    └───33,024 B (00.02%) ── compartment-tables
│  │    ├────327,680 B (00.15%) -- mjit
│  │    │    └──327,680 B (00.15%) ── code
│  │    ├────176,280 B (00.08%) -- objects
│  │    │    ├──164,800 B (00.08%) ── slots
│  │    │    ├────7,512 B (00.00%) ── misc
│  │    │    └────3,968 B (00.00%) ── elements
│  │    ├────150,056 B (00.07%) -- type-inference
│  │    │    ├───88,720 B (00.04%) ── object-main
│  │    │    ├───38,368 B (00.02%) ── script-main
│  │    │    └───22,968 B (00.01%) ── tables
│  │    ├─────42,352 B (00.02%) ── analysis-temporary
│  │    └─────17,144 B (00.01%) ── string-chars

now when  close 9gag.com tab and still have facebook.com tab open I have (after pressing minimize memory button many times):
├────400 B (00.00%) -- inner-window(id=352, uri=https://www.facebook.com/plugins/like.php?api_key=111569915535689&channel_url=https%3A%2F%2Fs-static.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df3d1c00768edae8%26origin%3Dhttp%253A%252F%252F9gag.com%252Ffa54797aaf742a%26relation%3Dparent.parent%26transport%3Dpostmessage&extended_social_context=false&href=http%3A%2F%2Ffacebook.com%2F9gag&layout=standard&locale=en_US&node_type=link&sdk=joey&send=false&show_faces=true&width=270)
│                 │    └──400 B (00.00%) ── dom
│                 

Even though this is only 400 B , but it was not present before opening the 9gag page, but is still left out after closing it. Thus is a zombie compartment.

If I close Facebook.com page now, then the compartment goes away and the memory is released.
IMO, this is not just Facebook's issue, but somehow Firefox thinks that the dom is still in use as it sees facebook.com in the url of the script and thus keeps it active. Once facebook.com is also closed, it releases the memory as it thinkgs that was associated with facebook.com tab ??

Comment 19

•

12 years ago

already reported that in another memshrink/js bug.

Comment 20

•

12 years ago

right above yours infact!

Comment 21

•

12 years ago

should this be marked as depends on bug 679942 ?

Comment 22

•

12 years ago

No No , the comment right above mine is about excessive usage of memory by small like buttons etc.
I am pointing out the fact that some portion of memory from these pages still remain even after closing the pages and lives as zombie compartments, until facebook.com tabs is not closed.
Memory used by opening/closing of 9gag or any other site that uses fb social plugin should not depend on the presence of facebook.com open in another tab.

Comment 23

•

12 years ago

these buttons are part of the very facebook social plugin system you refer to ;)

Comment 24

•

12 years ago

in my post, it displays facebook.com because that was the site that created the compartment initially.

the same pages open today have facebook load in 

│  ├───10.86 MB (01.98%) -- compartment(http://www.facebook.com/plugins/like.php?locale=en_US&href=http%3A%2F%2Fwww.facebook.com%2Fmangafoxlife&send=false&layout=button_count&width=100&show_faces=false&action=like&colorscheme=light&font&height=21&appId=141149349292130)

as the plugin was the compartment creator (from the mangafox site) instead of facebook.com

Comment 25

•

12 years ago

I am a little confused. What exactly do you mean ?

IMO what's the use of the button (or the memory used by the button) if the page containing the buttons have been closed. The memory should be released.

Comment 26

•

12 years ago

9gag created the compartment initial compartment for the facebook plugin, then you opened a instance of facebook in another tab.

the instance of facebook will use the plugin compartment created by the 9gag site as it has the same origin.

Thats why "https://www.facebook.com/plugins/like.php?api_key=111569915535689&..... " remains until you close the facebook tab.

It can also remain open if any other tab you have opened implements a facebook plugin/script.

Comment 27

•

12 years ago

"Firefox’s JavaScript memory is segregated into compartments.  Roughly speaking, all memory used by JavaScript code that is from a particular origin (i.e. website) goes into its own compartment.  Firefox’s own JavaScript code also gets one or more compartments.  Compartments improve security and memory locality."

from http://blog.mozilla.com/nnethercote/2011/07/20/zombie-compartments-recognize-and-report-them-stop-the-screaming/

Comment 28

•

12 years ago

Ok, I see what you are saying.
But I opened the FB page first, then 9gag. and closed 9gag first then fb.

Also I am aware of the way JS compartments behave. Its just that even if another tab/site created the compartment of the same origin as that of facebook.com, closing the tab should have removed the memory. Isn't it ?
I think then this flaw is by design?

Nicholas Nethercote [inactive]

Comment 29

•

12 years ago

if the flaw is that the compartment namespace doesn't change to the current open domain, then yes.

Comment 30

•

12 years ago

scrapmachines, you're talking about zombie compartments but most of what you've copied are entries showing inner windows.  It's not clear to me there's a problem.  

But if you think there is a problem, can you please open a separate bug?  Things are much simpler if we stick to one issue per bug, and this bug is about large Facebook compartments.  Thanks.

Depends on: 679942

Comment 31

•

12 years ago

As something to check, i just installed the antisocial subscription for ABP and the amount of zombie compartments occuring dropped dramatically (to none infact). Just to note i was not able to generate zombies normally with a quick run through with my usual extensions enabled, only with extended usage.

With how these plugins and scripts choke the JS memory use, its possible some of these zombie compartments are occuring in the JS compilation, particularly when opening a great number of sites that use these social media plugins.

Nobody; OK to take it and work on it

Comment 32

•

12 years ago

I should also mention that blocking the facebook scripts alone dropped GC times by around half. (for my session, from 680ms to 360ms)

Grinch

Comment 33

•

10 years ago

since a few days I have the same problems with this script window. At the moment Seamoney 2.25 Beta 1 uses about 750 MB (with Java & Flash Player) and about 14 or 15 Tabs in five windows. I spend some time into Facebook, just writing and sharing some things, playing one or two games) and from this moment the CPU usage rises high.. a bit down, then up again. And few moments later this "script follow or stop" occurs. But none of those options are useful, but the memory Usage of Seamonkey is about 1600 MB. So I guess there are some problems with Java especially in this Facebook webpage. With Opera i don't have these problems.

Flags: needinfo?(general)

Assignee

Updated

•

10 years ago

Assignee: general → nobody

Grinch

Updated

•

10 years ago

Flags: needinfo?(general)

Desigan Chinniah [:cyberdees] [:dees] [London - GMT]

Updated

•

8 years ago

platform-rel: --- → ?

Whiteboard: [MemShrink:P2] → [MemShrink:P2][platform-rel-Facebook]

Desigan Chinniah [:cyberdees] [:dees] [London - GMT]

Updated

•

7 years ago

platform-rel: ? → ---

Comment hidden (spam)

Daniel Veditz [:dveditz]

Updated

•

7 years ago

Attachment #8831986 - Attachment is obsolete: true

BMO Automation

Updated

•

2 years ago

Severity: normal → S3

BugBot [:suhaib / :marco/ :calixte]

Comment 35

•

2 years ago

The severity field for this bug is relatively low, S3. However, the bug has 13 votes.
:sdetar, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdetar)