1350307 - WebAssembly.Module, WebAssembly.Instance, WebAssembly.Table and WebAssembly.Memory do not have a size in the DevTools Memory profiling view

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Jukka Jylänki]

Attachment: webassembly_in_devtools_memory.png

Not sure whether this should be categorized in Developer Tools: Memory, but reporting here assuming that the JS engine code will need to assist the devtools to report the sizes. (feel free to reassign if this is not something the JS engine side needs to adapt to)

STR:
1. Visit https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html
2. Open DevTools Memory profiling tool and do a snapshot.
3. Choose the View: to Aggregate and Group by: to Type.
4. Find the WebAssembly related objects in the view.

Observed:

None of these objects have their real sizes associated with them, but they are each shown as 64 bytes. See the attached screenshot. However when taking an about:memory snapshot, these are shown as

│  │  │  │  ├──167.21 MB (17.13%) -- class(WebAssembly.Module)/objects
│  │  │  │  ├───80.84 MB (08.28%) -- class(WebAssembly.Instance)/objects

Not having the actual size makes it difficult to find these objects in the Memory tools, since they don't bubble up to the top of the view.

Comment 1

[Luke Wagner [:luke]]

Benjamin, ISTR you knowing what GC objects need to do to show up in the Memory tool?

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

So there's this byteSize() function in shell, and it shows the same incorrect results as described in comment 0.

Looking at the impl of this function [0], it calls into js::ubi::Node::size(). Since wasm objects are JSObjects, we should probably add a few conditions in JSObject::addSizeOfExcludingThis [1].

[0] http://searchfox.org/mozilla-central/source/js/src/builtin/TestingFunctions.cpp#3351
[1] http://searchfox.org/mozilla-central/source/js/src/jsobj.cpp#3779

Comment 3

[Jukka Jylänki]

For some background, the source of the issue was in the Zen Garden html page where the site was clinging on to the WebAssembly.Module after it had been instantiated, which mean it was wasting unneeded memory at runtime by having both the Module and the Instance alive, even though the Module is no longer needed after instantiation. About:memory snapshot was able to show memory for these both, but trying to hunt down what actually was keeping a reference to WebAssembly.Module turned out to be hard since it drowned into the Memory devtool tab at the bottom as a tiny 64 byte allocation and not a 167.21 MB allocation like about:memory said. (and to make things harder, bug 1350301 and bug 1350304 keep the UI from playing nice)

Fixed the memory wastage on the live site URL from comment 0, so about:memory there will not show up the Module anymore, the WebAssembly.Module object is now properly released after instantiate finishes. If you want to run a test case where both the Module and the Instance are still being held on to, you can download an earlier local copy of the demo from https://s3.amazonaws.com/mozilla-games/ZenGarden/2017-03-16-ZenGarden.zip.

Comment 4

[Benjamin Bouvier [:bbouvier] (inactive)]

I was looking at this, but unfortunately, it doesn't seem as simple as expected, because wasm can internally share some memory (for metadata, code, etc.).

The UbiNode machinery is a bit complex and it doesn't seem a particular ubi::Node instance can contain any supplementary data. In our case, we'd want some sets (namely, to remember which shared entities have already been seen and shouldn't be recounted). A solution to this would be to put these sets in the wasm::Compartment e.g., but this is error-prone: we'd have an external method to reset these sets at precise points and we would need to not forget resetting these sets.

I also thought of putting the sets in the ClassInfo itself, but its initialization isn't fallible, and that wouldn't solve the issue of recounting.

Nick, as the main author as far as I remember of all the ubi machinery, did you ever encounter a similar situation? If so, how did you solve it? If not the right person to ask, who would that be?

Comment 5

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Benjamin Bouvier [:bbouvier] from comment #4)
> wasm can internally share some memory (for metadata, code,
> etc.).

Anything that is shared should generally have its own JS::ubi::Concrete specialization so it is its own node in the graph. Then, you would need to override an appropriate JS::ubi::Concrete::edges implementation to return an edge range that included an edge to the shared data.

This way, the resulting graph directly and precisely shows how much sharing is going on based on how many incoming edges the shared thing has.

> The UbiNode machinery is a bit complex and it doesn't seem a particular
> ubi::Node instance can contain any supplementary data. In our case, we'd
> want some sets (namely, to remember which shared entities have already been
> seen and shouldn't be recounted).

Managing what has already been seen is handled by the various JS::ubi::Node graph traversals. Just make shared data its own node in the graph and then analyses and traversals will just do the Right Thing.

> If not the right person to ask, who would that be?

Both JimB and I can field these questions. I'm happy to help! :)