Closed Bug 1867453 Opened 8 months ago Closed 8 months ago

Nightly spends tons of time (2 minutes+) around GC on an online OCR tool. The time increases exponentially as the size of the image increases

Categories

(Core :: JavaScript Engine, defect)

defect

Tracking

()

RESOLVED FIXED
122 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox120 --- wontfix
firefox121 --- wontfix
firefox122 --- fixed

People

(Reporter: mayankleoboy1, Assigned: jonco)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: regression)

Attachments

(2 files)

Go to https://webbrowsertools.com/image-reader/
Select the attached image as the input (which is a 10MB file)

https://share.firefox.dev/49VG3T7

2MB input -> 6 seconds in GC
3MB input -> 14 seconds in GC
10MB input -> 132 seconds in GC
15MB input -> I gave up after few minutes

Attached image geometric_129.jpg

This is actually a regression. Regression range :
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c51b325c09f22a0d9384cfc5198f27ec9bdbfc8&tochange=94ad3527d1383d99f5a68be6432a8d50b6ed5ad2

Potential regressors : Bug 1751162

In the "good" versions, the memory use starts at 800MB. In the "bad" versions, the memory starts at 300MB.

Type: task → defect
Keywords: regression

This is another instance of quadratic behaviour allocating a lot of nursery things and putting them in a stack rooted vector. The allocation repeatedly triggers minor GC and the whole vector is traversed every time.

Assignee: nobody → jcoppeard

(In reply to Mayank Bansal from comment #2)

Potential regressors : Bug 1751162

Not really due to this, although this made it worse by reducing the nursery size and hence increase the number of nursery collections.

Considering the other bugs filed for similar issue (bug 1853305 and co), would it be worthwhile to do a systematic check /audit of all such cases? Or is it more efficient practically to tackle this on a bug-by-bug basis (as these issues usually occur for "large" testcases and thus probably an edge-ish case)

The problem is that the stack rooted vector of properties gets traced on every
minor GC. We allocate a nursery string for every dense array index in the given
array which may trigger a number of minor GCs, leading to quadratic runtime.

The fix is to switch to the tenured heap after the second minor GC, in the same
way we have done for other instances of this problem.

Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5c1bdf739b56
Fix quadratic behaviour enumerating own properties r=sfink
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch

This is fixed: (10MB input) https://share.firefox.dev/47EPrsV / (15MB input) https://share.firefox.dev/3RpFgTj
Thanks Jonco!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: