1536006 - Significant memory spike on aliexpress.com when moving cursor

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect, P1)

Description

[Kestrel]

Attachment: memory-report.json.gz

STR:

1. Go to https://www.aliexpress.com (homepage, search results or item listings).
2. Move cursor in circles rapidly around page for several seconds until memory spikes.

Content process suddenly jumps +600MB for several seconds. Memory report shows spike occurs in jit-lazylink. Performance recording shows it is related to a mousemove event and involving JIT for the following:

https://assets.alicdn.com/g/secdev/nsv/1.0.58/ns_b_69_3_n.js

Not a recent regression, can be reproduced on 2017-08-01 build.

Comment 1

[Kestrel]

Attachment: profile.json

Comment 2

[Eric Rahm [:erahm]]

For reference:

698.16 MB (100.0%) -- explicit
├──608.58 MB (87.17%) -- js-non-window
│  ├──603.59 MB (86.46%) -- runtime
│  │  ├──597.66 MB (85.60%) ── jit-lazylink
│  │  └────5.94 MB (00.85%) ++ (14 tiny)

Ted, it looks like you might know more about the jit-lazylink measurement.

Comment 3

[Ted Campbell [:tcampbell]]

This case is pretty wild. The |jit-lazylink| category includes deferred IonBuilders and their associated data. In this case we have IonBuilder loop restarts blowing up.

This is the memory-space version of Bug 1375631. I'll take it in this cycle because it has dragged on long enough..

Comment 4

[Jan de Mooij [:jandem]]

Does this still repro with the latest Nightly? Bug 1382650 might have helped a bit, depending on how much inlining is going on.

Comment 5

[Kestrel]

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

Does this still repro with the latest Nightly? Bug 1382650 might have helped a bit, depending on how much inlining is going on.

Yes, I can still reproduce memory spikes of the same magnitude on latest Nightly 2019-03-31.

797.59 MB (100.0%) -- explicit
├──700.38 MB (87.81%) -- js-non-window
│  ├──695.11 MB (87.15%) -- runtime
│  │  ├──688.28 MB (86.29%) ── jit-lazylink
│  │  └────6.84 MB (00.86%) ++ (14 tiny)

Comment 6

[Jan de Mooij [:jandem]]

This should be fixed in the next Nightly (bug 1547721).

IonBuilder still uses more memory than we would like (when I instrumented the MIR/LIR optimization passes it showed almost all of it is allocated by IonBuilder), but that bug addresses some of the worst-case issues like here.

Comment 7

[Kestrel]

I tested the previous 2019-04-28 build to make sure I could still reproduce it, then I tested the 2019-04-29 build and the memory spikes are gone.