1470990 - AWSY base case explicit and USS measurements are bimodal

Status: NEW

(Testing :: AWSY, enhancement, P3)

Description

[Eric Rahm [:erahm]]

It's going to be hard to turn on reporting if our measurements continue to be bimodal. Currently we load 4 pages to avoid dealing with the preallocated process and just measure the first one that comes back. Instead we could limit the process count to 1 and that might make things more stable. It's also possible that activity stream is somehow playing into this. There's a pref we can set to exclude that.

Comment 1

[Eric Rahm [:erahm]]

Looking at about:memory for one of the reports and modifying it to diff two of the content processes we can see the difference is:

> 1.82 MB (100.0%) -- explicit
> ├──2.13 MB (116.91%) ── script-preloader/heap/saved-scripts
> ├── -0.22 MB (-11.92%) ++ js-non-window
> ├── -0.09 MB (-5.09%) -- heap-overhead
> │  ├── -0.06 MB (-3.23%) ── bin-unused
> │  ├── -0.02 MB (-1.28%) ── page-cache
> │  └── -0.01 MB (-0.58%) ── bookkeeping

So it looks like the script preloader is probably the root cause. It might make sense to load Firefox once, pause for a bit (enough time for the script-preloader to do it's thing), reload Firefox and then do the real test.

Comment 2

[Kris Maglione [:kmag]]

See bug 1470793.

This is a bug in sessions where we don't have a startup cache. The first process clears the XDR data that it generates for scripts in the content process, but subsequent processes don't, since we never ask them for their XDR data.

We definitely should run Firefox once to initialize the startup caches first, though. That's the setup users are going to experience for the vast majority of sessions, so it's the one we should care the most about.

Comment 3

[Eric Rahm [:erahm]]

Also note we have a reverse bi-modality of about 200K for JS:

> -0.22 MB (100.0%) -- js-main-runtime
> ├──-0.13 MB (60.85%) -- realms
> │  ├──-0.08 MB (34.52%) -- scripts
> │  │  ├──-0.05 MB (21.06%) ── gc-heap
> │  │  └──-0.03 MB (13.46%) ── malloc-heap/data
> │  ├──-0.04 MB (19.92%) -- classes/objects
> │  │  ├──-0.04 MB (18.77%) ── gc-heap
> │  │  └──-0.00 MB (01.15%) ── malloc-heap/slots
> │  ├──-0.01 MB (03.68%) -- type-inference
> │  │  ├──-0.01 MB (03.01%) ── type-scripts
> │  │  └──-0.00 MB (00.67%) ++ (2 tiny)
> │  ├──-0.00 MB (02.24%) ── script-counts-map
> │  └──-0.00 MB (00.49%) ++ (2 tiny)
> ├──-0.08 MB (35.22%) -- zones
> │  ├──-0.04 MB (20.06%) -- scopes
> │  │  ├──-0.03 MB (11.58%) ── malloc-heap
> │  │  └──-0.02 MB (08.48%) ── gc-heap
> │  ├──-0.02 MB (07.91%) -- strings
> │  │  ├──-0.01 MB (05.53%) -- gc-heap
> │  │  │  ├──-0.01 MB (05.51%) ── latin1
> │  │  │  └──-0.00 MB (00.02%) ── two-byte
> │  │  └──-0.01 MB (02.39%) -- malloc-heap
> │  │     ├──-0.00 MB (02.27%) ── latin1
> │  │     └──-0.00 MB (00.11%) ── two-byte
> │  ├───0.01 MB (-6.42%) -- lazy-scripts
> │  │   ├──0.01 MB (-4.55%) ── gc-heap
> │  │   └──0.00 MB (-1.88%) ── malloc-heap
> │  ├──-0.01 MB (04.50%) ── object-groups/gc-heap
> │  ├──-0.01 MB (03.63%) -- shapes
> │  │  ├──-0.01 MB (03.06%) -- gc-heap
> │  │  │  ├──-0.01 MB (02.72%) ── tree
> │  │  │  └──-0.00 MB (00.34%) ++ (2 tiny)
> │  │  └──-0.00 MB (00.58%) ── malloc-heap/tree-kids
> │  ├──-0.01 MB (03.59%) ── type-pool
> │  ├──-0.01 MB (03.12%) ── compartments/cross-compartment-wrapper-tables
> │  ├───0.01 MB (-2.56%) ── unused-gc-things
> │  └──-0.00 MB (01.39%) ── gc-heap-arena-admin
> └──-0.01 MB (03.93%) ── runtime

So there's a decrease in JS overhead when saved-scripts has entries.

Comment 4

[Kris Maglione [:kmag]]

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #3)
> So there's a decrease in JS overhead when saved-scripts has entries.

Yeah, though those are sort of separate side-effects of the same issue.

The increase in explicit is because bug 1470793 prevents us from freeing unused XDR data in content processes when we load without the startup cache.

The increase in JS is because when we *do* load with the startup cache, we have to clone scripts that are loaded into compartments other than the shared JSM global. When we load without it, we compile them for the first global they're used in, and only need to clone when they're loaded into additional globals later.

Either way, we have the same number of entries in the saved-scripts cache, though.


We might be able to get away with an optimization where we throw away saved scripts that we know are only ever going to be loaded into one global. Figuring out which ones to throw away might be tricky, though...