1872221 - With Concurrent Delazification(strategy 2 or 3) , there is a 200ms GC (100ms+100ms) 10seconds after loading a Codepen demo

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Mayank Bansal]

If you already have opened codepen and/or loggedin, this may not repro. So,

Create new profile
Set dom.script_loader.delazification.strategy = 2 (or 3) . Restart the browser
Start the profiler.
Go to https://codepen.io/Tom-Fitzgerald/pen/yLZWENZ
(Optional: Once the page loads, place the mouse inside the demo-pane.)
Wait for 12-15 seconds.
Capture the profile.

Strategy 255: https://share.firefox.dev/47dPPh2 (Look at the GC thingy at the 10s and the 14s mark on PID-3704)
Strategy 2: https://share.firefox.dev/3vn0V5P (Look at the GC thingy between the 9s-10s marks on PID-18992)

Comment 1

[Nicolas B. Pierron [:nbp]]

Thanks for the report.

When using concurrent delazification (strategy 2 and 3), the code is parsed eagerly off-thread, and everything which is unused at the time of the first GC would be garbage collected and the delazification killed. So this behavior is expected in the sense that this is how it was designed.

However, this is a big memory consumption (~190 MB) compared to what it settles on after the first GC (~53 MB). The fun part is that the settled memory is less than the main-thread eager parsing (~60 MB).

Given that this appears on the first GC, this suggests that this memory consumption comes from the individual stencils of each functions stored in the Runtime cache.

One alternative might be to stop creating new stencils for each of the function, and start to merge functions into the stencils of their enclosing functions if they are not used by the main thread.

Reducing the memory pressure of the off-thread delazification would also be nice to reduce the memory pressure which was one of the pain point on Youtube.