1069711 - SIMD objects take up a lot of space at startup

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Nathan Froyd [:froydnj]]

I restarted my browser and ran about:memory; this is part of what it told me:

│  │  │  │  ├───85.14 MB (13.21%) -- classes
│  │  │  │  │   ├──39.61 MB (06.15%) -- class(Function)
│  │  │  │  │   │  ├──32.11 MB (04.98%) -- objects
│  │  │  │  │   │  │  ├──30.43 MB (04.72%) ── gc-heap [400]
│  │  │  │  │   │  │  └───1.68 MB (00.26%) ── malloc-heap/slots [400]
│  │  │  │  │   │  └───7.50 MB (01.16%) -- shapes
│  │  │  │  │   │      ├──7.32 MB (01.14%) ++ gc-heap
│  │  │  │  │   │      └──0.17 MB (00.03%) ── malloc-heap/tree-kids [400]
│  │  │  │  │   ├──26.55 MB (04.12%) -- class(<non-notable classes>)
│  │  │  │  │   │  ├──17.90 MB (02.78%) -- shapes
│  │  │  │  │   │  │  ├──16.68 MB (02.59%) -- gc-heap
│  │  │  │  │   │  │  │  ├───9.86 MB (01.53%) ── tree [400]
│  │  │  │  │   │  │  │  └───6.82 MB (01.06%) ++ (2 tiny)
│  │  │  │  │   │  │  └───1.22 MB (00.19%) ++ malloc-heap
│  │  │  │  │   │  └───8.65 MB (01.34%) ++ objects
│  │  │  │  │   ├──11.73 MB (01.82%) -- class(Object)
│  │  │  │  │   │  ├───8.41 MB (01.30%) -- shapes
│  │  │  │  │   │  │   ├──7.17 MB (01.11%) -- gc-heap
│  │  │  │  │   │  │   │  ├──6.35 MB (00.99%) ── tree [400]
│  │  │  │  │   │  │   │  ├──0.57 MB (00.09%) ── base [400]
│  │  │  │  │   │  │   │  └──0.24 MB (00.04%) ── dict [400]
│  │  │  │  │   │  │   └──1.24 MB (00.19%) ++ malloc-heap
│  │  │  │  │   │  └───3.32 MB (00.52%) ++ objects
│  │  │  │  │   └───7.25 MB (01.13%) -- class(SIMD)
│  │  │  │  │       ├──5.19 MB (00.81%) -- shapes
│  │  │  │  │       │  ├──5.15 MB (00.80%) -- gc-heap
│  │  │  │  │       │  │  ├──5.10 MB (00.79%) ── tree [400]
│  │  │  │  │       │  │  └──0.05 MB (00.01%) ── base [400]
│  │  │  │  │       │  └──0.04 MB (00.01%) ── malloc-heap/tree-kids [400]
│  │  │  │  │       └──2.06 MB (00.32%) -- objects
│  │  │  │  │          ├──1.95 MB (00.30%) ── malloc-heap/slots [400]
│  │  │  │  │          └──0.11 MB (00.02%) ── gc-heap [400]

That SIMD objects are immediately noted--comparable to Object instances!--in about:memory seems strange to me; I wouldn't expect these to be used widely, and the tabs that reload in my new browser session don't appear to be the kind of sites that would be jumping on new technology like SIMD.

So, where are these coming from, and why do they take up so much space?

Comment 1

[Nicholas Nethercote [inactive]]

What compartment are these in? The [400] suffix indicates that each of these paths are occurring in 400 reports. This might happen, for example, if you have 400 not-yet-restored tabs.

Comment 2

[Nathan Froyd [:froydnj]]

(In reply to Nicholas Nethercote [:njn] from comment #1)
> What compartment are these in? The [400] suffix indicates that each of these
> paths are occurring in 400 reports. This might happen, for example, if you
> have 400 not-yet-restored tabs.

I haven't counted in a while, but that sounds about right.  So we're eagerly instantiating these in chrome context?

Comment 3

[Nicholas Nethercote [inactive]]

As for the SIMD objects... you don't have many (gc-heap is low) but they are using up lots of slot memory (1.95 MiB) and there are lots of shapes. Which suggests lots of property setting on these objects.

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Nicholas Nethercote [:njn] from comment #1)
> What compartment are these in?

│  │  │  ├──115.28 MB (17.89%) -- compartment([System Principal], inProcessTabChildGlobal?ownedBy=chrome://browser/content/browser.xul)

Comment 5

[Nicholas Nethercote [inactive]]

> So we're eagerly instantiating these in chrome context?

Each not-yet-restored tab uses a small amount of memory... something like 100 KiB last time I measured. You're getting ~200 KiB, which is in the ballpark.

Comment 6

[Luke Wagner [:luke]]

That is a surprising amount and something we need to look into.  Just in case anyone was worried, though, SIMD is #ifdef NIGHTLY.

Comment 7

[Benjamin Bouvier [:bbouvier] (inactive)]

Bug 1067459 should probably help.

Comment 8

[Till Schneidereit [:till]]

(In reply to Benjamin Bouvier [:bbouvier] from comment #7)
> Bug 1067459 should probably help.

I'm not too sure. There is one self-hosting compartment, not 400. I think this is probably bug 919095: we eagerly initialize the builtins for each tab's outer global, IIRC. I stopped working on that back then because it wasn't really clear if it'd be a win in either direction, and there were bigger fish to fry. But really, picking that up again and driving it in is probably the right course of action here. Unfortunately, I won't be able to do so anytime soon, so feel free to steal.

Comment 9

[Benjamin Bouvier [:bbouvier] (inactive)]

Does the situation improved with bug 1084319 landed?

Comment 10

[Benjamin Bouvier [:bbouvier] (inactive)]

(In reply to Benjamin Bouvier [:bbouvier] from comment #9)
> Does the situation improved with bug 1084319 landed?

And I meant bug 1083238.

Comment 11

[Benjamin Bouvier [:bbouvier] (inactive)]

Bye bye SIMD.js.