Gregor Wagner [:gwagner] Reporter
	Description • 12 years ago

When opening this page I see around 2GB memory usage. If I click on another tab, the memory goes back to around 600MB.

About:memory only shows 300MB explicit memory for the 2GB RSS case.
I couldn't reproduce it with my old MBP without the retina display.

	Justin Lebar (not reading bugmail)
	Comment 1 • 12 years ago

Dietrich, can you do us a favor and not modify this page (or, if you do want to change it, make a copy first)?

	Nicholas Nethercote [inactive]
	Comment 2 • 12 years ago

Gregor, can you attach a copy of about:memory?  Just copy and paste the text into a file.

	Gregor Wagner [:gwagner] Reporter
	Comment 3 • 12 years ago

about:memory dump

	Nicholas Nethercote [inactive]
	Comment 4 • 12 years ago

How odd.  jemalloc clearly isn't allocating all that memory.  So I figure it must be either:

- The system allocator (a la bug 828844)

- Some mmap'd stuff.

Unfortunately we have no insight into either of those kinds of allocations :(

	Nicholas Nethercote [inactive]
	Comment 5 • 12 years ago

Oh, but I just learned about vmmap.  Run |vmmap <pid>| from the command line and you get tons of info (note that it takes a few seconds to run).  Hopefully that'll make it obvious.  The -resident flag might be helpful.

	Justin Lebar (not reading bugmail)
	Comment 7 • 12 years ago

Comment on attachment 700874 [details]
vmmap + about:memory

Looks like it's coming from a bunch of ~15mb mappings like

MALLOC_LARGE           00000001ea200000-00000001eb0fc000 [ 15.0M] rw-/rwx SM=PRV  GFXMallocZone_0x100086000
VM_ALLOCATE            00000001eb0fc000-00000001ebffc000 [ 15.0M] rw-/rw- SM=ALI  

It's gotta be the radial gradient, right?  There's nothing else in that page...

	Justin Lebar (not reading bugmail)
	Comment 8 • 12 years ago

Just tested this with Gregor.  Disabling the radial gradient didn't make a difference, but deleting the "ray" <div>s helped a ton.

  <div class="ray" style="transform: rotate(194.4deg);"></div>
  
  .ray {
    background-color: rgba(255, 255, 255, 0.1);
    width: 150%;
    height: 10px;
    position: fixed;
    top: 50%;
    left: -25%;
    z-index: -1;
  }

	Jet Villegas (inactive)
	Comment 9 • 12 years ago

+cc: Jonathan. Can you comment on the memory usage in the dynamically generated divs here? There doesn't seem to be much in there but text.

	Jet Villegas (inactive)
	Comment 10 • 12 years ago

To Milan for assignment. See comment 7 for the suspect allocations (GFXMallocZone_0x100086000)

	Jonathan Kew [:jfkthame]
	Comment 11 • 12 years ago

(In reply to Justin Lebar [:jlebar] from comment #8)
> Just tested this with Gregor.  Disabling the radial gradient didn't make a
> difference, but deleting the "ray" <div>s helped a ton.
> 
>   <div class="ray" style="transform: rotate(194.4deg);"></div>
>   
>   .ray {
>     background-color: rgba(255, 255, 255, 0.1);
>     width: 150%;
>     height: 10px;
>     position: fixed;
>     top: 50%;
>     left: -25%;
>     z-index: -1;
>   }

It looks like the page creates 50 of these <div>s, and many of them (depending on their angle) will have a pretty large bounding box. I don't know how Layers would handle this, but if we're creating a separate layer and opengl backing surface for each of these (are we?), that'd add up to a lot of allocation for all those surfaces. On a retina display, they'd be 4x the size that they are on a similar-sized non-retina display, as they'll be created at device resolution.

Where would memory for opengl backing store show up - can/do we track that?

	Justin Lebar (not reading bugmail)
	Comment 12 • 12 years ago

> Where would memory for opengl backing store show up - can/do we track that?

I don't think we do track these.  I'd love it if we could, but it's hard; the allocations don't even go through malloc().

I guess we could do something like

    StartingOGLCallOnThisThread();
    [OGL stuff]
    StoppingOGLCallOnThisThread();

and then intercept mmap() between the Start and Stop calls...

	Justin Lebar (not reading bugmail)
	Comment 13 • 12 years ago

> On a retina display, they'd be 4x the size that they are on a similar-sized non-retina 
> display, as they'll be created at device resolution.

Okay, I see a ~330mb jump when I focus the tab, so 4x that is 1300mb, which roughly corresponds to the increase Gregor saw.  Good to know this isn't a retina-only problem.

	Justin Lebar (not reading bugmail)
	Comment 14 • 12 years ago

johns suggests that perhaps there's an Apple OGL extension which would let us query how much memory the graphics driver is using.

	Kelsey Gilbert [:jgilbert]
	Comment 15 • 12 years ago

I think we would be better served by estimating our GL memory usage ourselves, which should work on all platforms, and is something we've wanted to do for a while.

	Milan Sreckovic [:milan] (needinfo for best results) Assignee
	Comment 16 • 12 years ago

In the context of using too much memory - Avi, Jeff, is this the gradient cache miss issue?

	Avi Halachmi (:avih)
	Comment 17 • 12 years ago

(In reply to Milan Sreckovic [:milan] from comment #16)
> In the context of using too much memory - Avi, Jeff, is this the gradient
> cache miss issue?

The cache misses issue we were dealing with at bug 837542 and bug 838758 is strictly a Windows/D2D issue. So I would say it's probably not the same issue.

	Milan Sreckovic [:milan] (needinfo for best results) Assignee
	Comment 18 • 12 years ago

Thanks Avi, didn't realize Windows/D2D is the only place where we cache the gradients.

	Eric Rahm [:erahm]
	Comment 19 • 7 years ago

Milan do you know if this is still an issue or should we just close it? The test site is gone so I can't confirm one way or another.

	Milan Sreckovic [:milan] (needinfo for best results) Assignee
	Comment 20 • 7 years ago

Let's deal with issues we can reproduce and work with.