We should figure out whats going on here.
blocking2.0: --- → final+
I'll ask some help from the Nightly-testers mailinglist, to see if someone else can reproduce. I'll also attach the PAC file in a moment.
Not sure exactly what those functions do, but it looks like this could be creating a zillion regexps and compiling them to native code. It could be a leak, but maybe we just need a discard algorithm like we have for methodjit code.
(In reply to comment #4) > Not sure exactly what those functions do, but it looks like this could be > creating a zillion regexps and compiling them to native code. It could be a > leak, but maybe we just need a discard algorithm like we have for methodjit > code. I suppose if it started only after compartment GC landed, then it more likely is a leak.
(In reply to comment #5) > (In reply to comment #4) > > Not sure exactly what those functions do, but it looks like this could be > > creating a zillion regexps and compiling them to native code. It could be a > > leak, but maybe we just need a discard algorithm like we have for methodjit > > code. > > I suppose if it started only after compartment GC landed, then it more likely > is a leak. maybe bug 587288 ?
(In reply to comment #8) > (In reply to comment #5) > > I suppose if it started only after compartment GC landed, then it more likely > > is a leak. > > maybe bug 587288 ? That one landed to TM, so you could try the latest nightly and see if the problem is still there (unless you're already on it).
(In reply to comment #9) > That one landed to TM, so you could try the latest nightly and see if the > problem is still there (unless you're already on it). I am running the latest nightlies. I was thinking that the problem was *caused* by bug 587288, because it also appeared in the same build as I first saw it. And it mentions both regex and compartments. But that is just a wild guess. I'm starting to think it's relates to one of the YARR/regex changes. Apparently, my PAC file uses a lot of regex (I didn't wrote that monstrosity), which make the problem easy to detect. I'll try to repeat the problem without a PAC file, just a manually configured proxy server, but it will take some time, as this setup doesn't work through the VPN at home. I'll have to go to the office.
Bingo. When I configure a manual proxy (which is the same one as the bottom rule of attachment 503618 [details], and all test URLS were using that one anyway), I fall back to the same memory usage as without a proxy server. It seems indeed that it's caused by the regular expressions. Chris, do you have any idea ? gc_per_compartment gc_per_compartment == true == false PAC file 436,064,256 445,788,160 without PAC 274,132,99 269,496,320 manual proxy 272,568,320 272,441,344 Note that I repeated the tests several times and took an average of 3 requests requests, because the results can vary a lot (+- 30 MB easily), due to the large amount of simultaneous requests. PS : I forgot to mention that I didn't see this behavior in earlier nightlies, or in Firefox 3.6.*. It is a regression.
The list of test urls is this one : http://slashdot.org/ http://www.theregister.co.uk/ http://arstechnica.com/ http://www.deredactie.be/cm/vrtnieuws http://www.gva.be/ http://www.demorgen.be/ http://news.google.be/news?ned=nl_be http://news.google.be/news?ned=es_co http://news.google.be/news?hl=en&ned=us&q=alcatel&btnG=Search+News http://news.google.be/news?hl=en&ned=us&ie=UTF-8&q=colombia&btnG=Search+News http://www.lapatria.com/ http://www.cambio.com.co/archivo/buscar?producto=cambio&orden=reciente http://twitter.com/piedadcordoba http://www.buienradar.nl/h.aspx?jaar=-3&soort=loop1uur1x1 http://www.google.com/finance?q=EPA:ALU
The memory leak seems to be gone, now that bug 626118 is fixed. Running with a PAC file still consumes a lot more memory than without one (due to the complexity of attachment 503618 [details]). But during normal surfing (not loading all at once), it doesn't hurt anymore. And the memory is reclaimed, which was this bug.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Summary: memory leak when using PAC file since comparent-gc is enabled → memory leak when using PAC file (regex ?)
This is available in 43-44 version of firefox. Without regexps for some load browser consume 500M, with pac-file with 400 regexps with same load it consume 1.6G
You need to log in before you can comment on or make changes to this bug.