1501238 - Twitch.tv live stream wasm web worker has high memory fluctuations

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect, P3)

Description

[Kestrel]

Attachment: mem-graph.png

Viewing a live Twitch stream can see memory fluctuate significantly, averaging 750MB and exceeding 1GB at the peaks while Chromium remains relatively stable at 350MB (see graph). Testing was done on Ubuntu 18.10 with each browser displaying the same Twitch stream simultaneously.

about:memory seems to indicate this is due to a wasm web worker with most allocations in class(ArrayBuffer) malloc-heap.

https://cvp.twitch.tv/2.6.29/wasmworker.min.js

Comment 1

[Kestrel]

Attachment: memory-report.json.gz

Comment 2

[Lars T Hansen [:lth]]

From the picture, this smells like memory growth followed by some kind of GC or (more likely) malloc coalescing, though I've not looked at the memory report yet.

Comment 3

[Luke Wagner [:luke]]

Are the ArrayBuffers the normal kind (with the fluctuations under malloc-heap/elements -- normal) or the special wasm/asm.js kind (with the fluctuations under non-heap/elements/wasm or malloc-heap/elements -- asm.js)?

If it's the former, than I would expect the difference we're seeing here relates to worker GC scheduling and is not directly tied to wasm.

Comment 4

[Kestrel]

The fluctuating ArrayBuffers are the normal kind (malloc-heap/elements/normal).

Comment 5

[Luke Wagner [:luke]]

Ok, since, last I heard, worker GC scheduling is a known issue with possible plans to work on, I'll tentatively kick this over to the GC component.

Comment 6

[Andrew McCreight [:mccr8]]

The memory gradually ramping up over 5 minutes then dropping is weird. I wonder what sort of limit we're hitting. This sounds like either an issue with mallocbytes not being updated, so the GC doesn't realize it needs to run, or maybe the memory was GCed, but some communication back to the main thread that is needed to finally release things is being delayed. I guess the latter doesn't sound too likely given how long and how regular the spike then drop is.

Comment 7

[Jon Coppeard (:jonco)]

This is probably due to the way we track malloc memory associated with GC things. We don't have size information when we free malloc memory so we just track total allocation size since the last GC. If this hits a threshold we trigger a GC and increase the threshold. I suspect that GC is freeing the memory, but because we keep hitting this threshold we keep increasing it, so GCs become increasingly rare. Ideally we'd have retained size information which we would use to set the threshold appropriately.

Comment 8

[CoolCmd]

Firefox 66 still allocates 1 GiB of memory for 1 Twitch.tv tab.
I think this bug affects other video sites too.

Comment 9

[Jon Coppeard (:jonco)]

This doesn't seem to happen in nightly any more, but it didn't always reproduce for me. Can you check whether this is still a problem?

Comment 10

[Kestrel]

Attachment: mem-graph-after-fix.png

Comment 11

[Kestrel]

I can no longer reproduce this in latest Nightly on Ubuntu 19.04.

Fix window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=016f5882a4cb8eeeb7190370bef81a6ed0eeef88&tochange=c27a6d5810fe3a3a45177c6a7294b5041b26646b

Fixed by Bug 1569560.

Comment 12

[Jon Coppeard (:jonco)]

(In reply to Kestrel from comment #11)
\o/

Thanks for confirming.