Created attachment 8813213 [details] Memory report after GC User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161114145007 Steps to reproduce: Clone git clone https://github.com/WeatherMagic/weather-front/ cd weather-front git checkout 4f6a4f3 lein figwheel Once figwheel has started it should open your default browser to http://localhost:3449/ Now you'll simply have to let the application run. Actual results: You'll see that Firefox allocates increasingly large amounts of memory. On my 32-bit Ubuntu 16.04 system Firefox allocates increasing amounts of memory until it reaches 1.8GB of heap-unclassified soon after which it's properly GC'd. Expected results: The memory should be GC'd much sooner. In Chromium it's collected about every three seconds.
A working copy of the program can be found here: http://rovanion.se/weather-front/resources/public/
A perhaps related issue is https://bugzilla.mozilla.org/show_bug.cgi?id=1305389 A web server with this code running can be found here: http://rovanion.se/webgl-clojurescript-tutorial/resources/public/
So just to be clear, the STR is: #1 - Load http://rovanion.se/webgl-clojurescript-tutorial/resources/public/ #2 - Watch memory and CPU usage spike On a 53 debug/dmd build I can't even get a memory report to complete for the content process.
Sorry that i put info on the both bug reports in each other. For this bug the STR should be #1 - Load http://rovanion.se/weather-front/resources/public/ #2 - Watch memory and CPU usage spike
Yes, I've since making this bug noticed the cause of this: We were compiling the shader once per frame. I've produced a copy of the program which uses a magnitude less CPU, for obvious reasons, but which still leaks memory but at a slower pace of about 20MB/s. http://rovanion.se/weather-front-2/resources/public/
Worth noting is that I'm using the Intel drivers on an i7 2640M. With this second version of the program though the memory leak appears to be outside Firefox' address space since neither the virtual, resident or shared memory of Firefox in htop goes up; but then neither does any other precesses memory. But never the less the RAM gets filled up and so does the swap.
But it's clear that it's the application that's causing the allocation of the memory since it all deallocates once tab is closed. Same difference can be seen on mobile where firefox crashes running  after roughly ten seconds while the built in Android browser runs it without issues, indefinitely. Issue  is a destilled example of the extreme shader compilation like  which on my machine causes firefox to crash. Since the code in  has both the problem of that in  and , do you think we should let this bug be solely about ? But then again that invalidates the memory and dmd outputs so perhaps I should just start a new one for ?  https://bugzilla.mozilla.org/show_bug.cgi?id=1305389  http://rovanion.se/weather-front/resources/public/  http://rovanion.se/weather-front-2/resources/public/
We're keeping the ANGLE shader validator around because it's easy, not because it's required. This causes shaders to have an outsized memory impact, though it's usually fine for normal workloads. I'm interested by the outside-our-memory-space leak you're seeing. Does this reproduce if you set the pref layers.acceleration.disabled=false and restart the browser?
Flags: needinfo?(jgilbert) → needinfo?(rovanion.luckey)
Duplicate of this bug: 1305389
Whiteboard: [MemShrink] → [MemShrink:P1]
layers.acceleration.disabled=false was already the default value in my Firefox.
Jeff, any next steps here?
Flags: needinfo?(rovanion.luckey) → needinfo?(jgilbert)
I'll look into why this may be. I suspect we aren't communicating how large our GC object is, so the GC doesn't realize how much memory pressure there is. I do think this problem will go away if we aggressively discard/reset the ANGLE shader translator instance.
Assignee: nobody → jgilbert
Priority: -- → P2
Whiteboard: [MemShrink:P1] → [MemShrink:P1] gfx-noted
You need to log in before you can comment on or make changes to this bug.