Cookie clicker game causes high heap-unclassified; on Linux it's due to libmurrine

RESOLVED INCOMPLETE

Status

()

Core
General
RESOLVED INCOMPLETE
4 years ago
10 months ago

People

(Reporter: dzbarsky, Assigned: mccr8)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(5 attachments)

(Reporter)

Description

4 years ago
My guess is that it's http://orteil.dashnet.org/cookieclicker/
(Reporter)

Comment 1

4 years ago
Created attachment 803811 [details]
memory-report.json.gz
(Assignee)

Comment 2

4 years ago
In IRC, dzbarsky said he was getting this:
   1,839.64 MB (67.23%) ── heap-unclassified
He's going to make a local DMD build and see what it turns up.
Whiteboard: [MemShrink]
(Assignee)

Updated

4 years ago
Summary: Page is using lots of memory → Page is using lots of memory (high heap-unclassified)
> My guess is that it's http://orteil.dashnet.org/cookieclicker/

I think I can reproduce, but the game has to run for a long time, because heap-unclassified increases slowly.  Fortunately the game basically runs itself.
dzbarsky, have you had a chance to do a DMD run?
Flags: needinfo?(dzbarsky)
Whiteboard: [MemShrink] → [MemShrink:P2]
(Reporter)

Comment 5

4 years ago
I tried running it, but firefox crashed when I ran DMDReportAndDump.  This was on OSX 10.8, maybe it works better on linux?
Flags: needinfo?(dzbarsky) → needinfo?(n.nethercote)
Created attachment 807496 [details]
DMD output from Linux

I ran the game for about 20 hours.  heap-unclassified crept up from 16MB/~16% to 70MB/~35% in that time.  Attached are the top 10 reports from the DMD output.

Unfortunately, the main source of heap-unclassified is libmurrine, which appears to be part of GTK.  (http://rpmfind.net/linux/rpm2html/search.php?query=libmurrine say "The Murrine engine is a cairo-based GTK2 theming tool.")  It's going to be hard to measure that memory usage.  Also, there's a good chance that this library isn't used on OS X and so the heap-unclassified that dzbarsky saw is from a different source :(

There is also some unclassified memory being allocated under CreateHTMLElement().  We should be able to report that pretty easily.  bz, do you know where that ends up being stored?
Flags: needinfo?(n.nethercote) → needinfo?(bzbarsky)
Summary: Page is using lots of memory (high heap-unclassified) → Cookie clicker game causes high heap-unclassified; on Linux it's due to libmurrine
The GTK2 theming stuff is definitely not used on OSX.

The CreateHTMLElement bits in that output are just showing script doing document.createElement().  After that it's just a node... the script can store it a JS variable, put it in the DOM, etc.  But I thought we reported all nodes now?
Flags: needinfo?(bzbarsky)
(Assignee)

Comment 8

4 years ago
We track nodes that are in actively displayed documents, and those in documents that have nodes that are reachable from JS.  I'm not sure how else a page could keep nodes alive, but that's a question a CC log should be able to answer.
> that's a question a CC log should be able to answer.

Here's a question I should know the answer to:  what's the best way to get a CC log?  A google search suggested either (a) a magic javascript: invocation, or (b) about:cc, or (c) about:ccdump.
(Assignee)

Comment 10

4 years ago
Those all work. ;)  (though the last two require addons...) There's also environment variables.  But for this case you just want to do something like this: https://wiki.mozilla.org/Performance:Leak_Tools#Cycle_collector_heap_dump
Created attachment 808482 [details]
GC log
Created attachment 808484 [details]
CC log
mccr8, can you do your CC log magic?  Thanks.
Flags: needinfo?(continuation)
(Assignee)

Comment 14

4 years ago
Oops, I should have suggested that you get an AllTraces log, which is the third one in there. If you could get me one of those, I can look at it again. The CC log you attached isn't very interesting, so presumably whatever is causing the heap-unclassified is being optimized out of the CC graph.

From the GC log, these are the most common things:
  159008 shape
   51655 base_shape
   21522 HTMLSpanElement <no private>
   18980 Array <no private>
   16564 type_object
   15893 Object <no private>
   11727 Function

Presumably it is the span elements that are causing the heap-unclassified?  Pretty much all of the span elements are colored white, which is weird, because that means they've been allocated since the last GC?
Flags: needinfo?(continuation)
Created attachment 810750 [details]
allTraces CC log

> Oops, I should have suggested that you get an AllTraces log, which is the
> third one in there. If you could get me one of those, I can look at it
> again.

Here you go.  heap-unclassified was 120 MB (57%) after running for close to 24 hours when I took this.  Let me know if you need the GC log from that invocation as well.
Flags: needinfo?(continuation)
(Assignee)

Comment 16

4 years ago
I started looking at the log.  There's a ton of about:memory stuff.  Is that expected, Nick?

Other than that, I haven't come up with anything particularly useful.  I'll try digging around some more.
Flags: needinfo?(n.nethercote)
> I started looking at the log.  There's a ton of about:memory stuff.  Is that
> expected, Nick?

Somewhat.  I hit "measure" in about:memory a few times and the strings can build up between GCs when that happens.  (This is why I want to improve the string handling.)
Flags: needinfo?(n.nethercote)
(Assignee)

Comment 18

4 years ago
Well, what I'm seeing isn't strings per se, but tens of thousands of DOM nodes:
   20101 nsGenericDOMDataNode
    7525 JS Object
    3872 FragmentOrElement (xhtml) span class='treeline' about:memory
    3872 FragmentOrElement (xhtml) span class='mrValue' about:memory
    3872 FragmentOrElement (xhtml) span class='mrSep' about:memory
    3872 FragmentOrElement (xhtml) span class='mrName' about:memory
    3859 FragmentOrElement (xhtml) span class='mrPerc' about:memory
    2556 XPCWrappedNative
> Well, what I'm seeing isn't strings per se, but tens of thousands of DOM
> nodes:

That's believable too.  Every time you re-measure, all the existing DOM nodes (of which there are many) are discarded.
(Assignee)

Comment 20

4 years ago
Maybe I'll eventually be able to figure something out here...
Assignee: nobody → continuation
Flags: needinfo?(continuation)
(Assignee)

Comment 21

10 months ago
(In reply to Andrew McCreight [:mccr8] from comment #20)
> Maybe I'll eventually be able to figure something out here...

I didn't.
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.