Closed Bug 1037977 Opened 10 years ago Closed 10 years ago

High heap-unclassified after opening a lot of pdfs

Categories

(Toolkit :: about:memory, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: guijoselito, Unassigned)

Details

Attachments

(1 file)

I was going through some pdf viewer bugs here on bugzilla.
After testing some of them, and filling one bug, I checked about:memory and Windows' Task Manager.

Task Manager shows 520MB for Firefox (Nightly).
But about:memory shows something totally different.
I used the feature "Measure and save" and am attaching it here.
There is 720MB of explicit, with 51% of it being heap-unclassified.
These are some strange numbers:

>   720.01 MB -- explicit
>   367.62 MB ── heap-unclassified
>   590.66 MB ── heap-allocated
> 1,000.31 MB ── private
>   549.79 MB ── resident

It suggests(?) that there are large allocations -- mostly outside the heap, but also partly on the heap -- happening, but lots of the memory isn't being touched.

Are you in a position to do a build with DMD enabled? That will give us more info about the heap-unclassified. Instructions are at https://wiki.mozilla.org/Performance/MemShrink/DMD#Desktop_Firefox_.28Windows.29.
Unfortunately, I'm just an end user. But I'll try to find minimal steps to reproduce.
Just one note: that memory from heap-unclassified never went away. Just when I closed Firefox.
I couldn't reproduce the problem again, unfortunately.
The only thing I found is an easy way to produce a lot of heap-unclassified, but it is a stress test.
Open all of this PDFs[1] at the same time, and then close them. Maybe scrolling them is also important, mainly the last one, which is huge and loads a lot of fonts.

During the test, Firefox peaked at 2 GB. When I closed all of them, went to about:memory, clicked minimize memory usage and then "Measure". I got 30% of heap-unclassified (120 out of 400MB), which never went away.

[1]
https://bug844092.bugzilla.mozilla.org/attachment.cgi?id=717103
http://lib.tkk.fi/Dipl/2002/urn007413.pdf
http://www.tit-szfvar.sulinet.hu/versenyek/2012/matematika/MatekMegold6.pdf
http://www.kk-mic.jp/somu/kigyo/documents/h2205.pdf
http://miracle.rpz.name/shared/anketa.pdf
http://www.wakmet.com.pl/sites/default/files/katalog/00100_218%20%20ANG.pdf
https://bug762244.bugzilla.mozilla.org/attachment.cgi?id=630713
http://www.ic.unicamp.br/~pannain/mc404/aulas/pdfs/Art%20Of%20Intel%20x86%20Assembly.pdf
https://bug841806.bugzilla.mozilla.org/attachment.cgi?id=714461
https://bug846014.bugzilla.mozilla.org/attachment.cgi?id=826440
https://bug946506.bugzilla.mozilla.org/attachment.cgi?id=8342707
https://bug750664.bugzilla.mozilla.org/attachment.cgi?id=619898
http://www.oranjewoudnv.nl/sites/default/files/Oranjewoud%20NV%20-%20%20besluiten%20aandeelhoudersvergadering%2011%20juni%202014.pdf
http://studioforcreativeinquiry.org/public/warhol_amiga_report_v10.pdf
https://issues.apache.org/jira/secure/attachment/12521771/AnnahmeReport_MitRussischTest.pdf
http://www.w3.org/WAI/WCAG20/Techniques/working-examples/PDF17/page-numbers.pdf
https://issues.apache.org/jira/secure/attachment/12546323/missing_image.pdf
http://www.dynacw.co.jp/Portals/3/fontsamplepdf/sample_4942546800828.pdf
> I couldn't reproduce the problem again, unfortunately.

Given that, I will close this bug.

The good news is that I profiled pdf.js with most of the documents in comment 3. And there have been numerous recent improvements to pdf.js that reduce its memory usage.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: