Closed Bug 1594054 Opened 4 months ago Closed 3 months ago

massive amounts of js-non-window/runtime/code/unused memory

Categories

(Core :: JavaScript Engine: JIT, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: froydnj, Assigned: jandem)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 file)

I have a long-running session where almost all of my content process windows have a js-non-window/runtime/code/unused amount > 1GB, some approaching 2GB. The unused code is more than the baseline and ion code combined in all of those cases, sometimes significantly so.

I have to restart that session because of multiple processes consuming > 10GB vsize, but whatever got us to that point seems bad.

I think this measures ExecutableAllocator usage. Jan, what could cause this?

Component: JavaScript Engine → JavaScript Engine: JIT
Flags: needinfo?(jdemooij)

(In reply to Nathan Froyd [:froydnj] from comment #0)

I have a long-running session where almost all of my content process windows have a js-non-window/runtime/code/unused amount > 1GB, some approaching 2GB.

On 64-bit platforms, MaxCodeBytesPerProcess is 2 GB...

The unused code is more than the baseline and ion code combined in all of those cases, sometimes significantly so.

ExecutableAllocator is a per-runtime (JS thread) bump allocator for JIT/IC code. Pools are typically 64 KB, but can be bigger for larger allocations. If "unused" is a lot, it means there are probably many pools that are mostly empty but still kept alive by a small number of JitCode instances, so we can't free them yet...

Jon, do you know if there have been any GC scheduling changes recently that could explain this? I wonder if we should account better for memory associated with the JitCode GC things, although it's not malloc memory. The jitHeapThreshold threshold seems fairly high and doesn't kick in if there are multiple zones contributing, as far as I can tell.

Another option is to have an ExecutableAllocator per zone instead of runtime. It could end up wasting a bit more memory but it would also help avoid fragmentation...

Flags: needinfo?(jcoppeard)

(In reply to Jan de Mooij [:jandem] from comment #2)

Jon, do you know if there have been any GC scheduling changes recently that could explain this?

There were a bunch of scheduling changes around August but not since then.

We do track used JIT code memory per zone, but as you said the trigger level is pretty high and we're unlikely to trigger GC based on this. We could try reducing this.

Having said that, if the problem is unused memory it sounds like most of the JitCode things have been collected anway, so maybe fragmentation is the real issue. Having an ExecutableAllocator per zone sounds like a good idea. Maybe the default pool size could be reduced, or could start of smaller for zones that don't allocate much code.

Another possibility is that we missed collecting some zones, which was a problem that bug 1592598 should have helped with.

Nathan, I don't suppose you have STR?

Flags: needinfo?(jcoppeard)

Unfortunately, STR for these sorts of things are "browse normally for N weeks, and then look at about:memory" :( The browser window(s) that I've had open for ~24 hours look pretty normal. :(

Whiteboard: [MemShrink] → [MemShrink:P2]

I will experiment with a per-Zone allocator this week or next week and see how it affects our AWSY numbers on Try...

From what I see on Try so far, moving the ExecutableAllocator from JitRuntime to JitZone doesn't really affect our AWSY numbers.

I think it's a good idea: it matches GC allocation, will help avoid fragmentation and if someone does see this again we can check which zone is responsible.

Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Flags: needinfo?(jdemooij)

This matches the JitCode GC-thing lifetime and will hopefully help avoid
fragmentation.

Pushed by jdemooij@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ba1518c4b5e8
Move ExecutableAllocator from JitRuntime to JitZone. r=jonco,erahm
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

== Change summary for alert #23962 (as of Thu, 14 Nov 2019 18:56:33 GMT) ==

Improvements:

2% Base Content JS windows7-32 opt 3,110,110.67 -> 3,044,836.00
2% Base Content JS windows7-32-shippable opt 3,110,106.67 -> 3,044,840.00
2% Base Content JS linux64 opt 3,957,361.33 -> 3,891,925.33
2% Base Content JS linux64-shippable opt 3,957,449.33 -> 3,892,194.67
2% Base Content JS linux64-shippable-qr opt 3,957,506.67 -> 3,892,302.67
2% Base Content JS linux64-qr opt 3,957,377.33 -> 3,892,309.33
2% Base Content JS macosx1014-64-shippable opt 3,958,376.00 -> 3,893,312.00
2% Base Content JS windows10-64-qr opt 4,021,068.00 -> 3,956,109.33
2% Base Content JS windows10-64-shippable opt 4,021,044.00 -> 3,956,089.33
2% Base Content JS windows10-64 opt 4,020,957.33 -> 3,956,212.00
2% Base Content JS windows10-64-shippable-qr opt 4,020,965.33 -> 3,956,237.33

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=23962

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